Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: ntpt 16. 10. 2016, 14:11:54
-
Dobrý den,
Má někdo tip na dobrý javascript obfuscator, který:
1 je free (lgpl atd)
2 není triviálně neutralizovatelný
3: výstup je náhodný (tedy jeden a tentýž js na vstupu produkuje mnoho variant výstupu)
děkuji
-
Perl.
-
Z principu nic takoveho neexistuje, jak jednou das zdrojak ven tak zahmleni nazvu promennych nebo funkci nic neresi i kdyby ty nazvy byli pokazde nahodne. Jakykoli prettyfier muze prinejhorsim sahnout po abstract syntax tree a vystup bude pokazde stejnej.
Proste to neres a vubec se tim nezapodivej a kdyz ti to nakazalo sefstvo tak je posli do <>.
-
K cemu presne vam ma byt obfuskator, kdyz deobfuskatoru clovek najde tri prdele i online?
-
K cemu presne vam ma byt obfuskator, kdyz deobfuskatoru clovek najde tri prdele i online?
http://javascript2img.com/
který deobfuskátor zvládne deobfuskovat tohle?
-
napr.
http://megascouts.ml/deobfuscate/ (http://megascouts.ml/deobfuscate/)
-
http://javascript2img.com/
který deobfuskátor zvládne deobfuskovat tohle?
Kdyz to umi prelouskat bowser, umi to ůprelouskat i nekdo jiny. To by se musel JS provadet na serveru a do browseru posilat jen vyrenderovany obraz.
-
Navíc se na webu povalují zdrojáky celkem dobrých databází, operačních systémů, grafických a video editorů... A někdo potřebuje chránit "pár kilo" klientského skriptu pro ovládání něčeho v prohlížeči (když logika aplikace jde bez problémů "schovat" na server)... Co zrovna na JS může být tak sofistikovaného a hodného ochrany? ;)
-
Tohle je nesmysl. Neochranis. Zadnej JS nikdy neni necim co by stalo za to chranit.
-
Jediný význam obfuskace v Javascriptu vidím ve zrychleném parsování.
-
Co zrovna na JS může být tak sofistikovaného a hodného ochrany? ;)
Asi napsal nejake desne unikatni Hello world.
-
Prosím ponechejte zkoumání mých důvodů, buďte s ijisti, že nějaké jsou. Jsem si samozřejmě vědom slabosti tohoto přístupu, nepotřebuji o něm poučovat.
Víte li tedy o něčem prosím doporučte. Zejména s ohledem na bod 3
Odpovědi , které jsou jen slušně zaoblené insulty typu "jen debil se na něco takvýho může zeptat" opravdu nejsou na úrovni. Děkuji.
-
Navíc se na webu povalují zdrojáky celkem dobrých databází, operačních systémů, grafických a video editorů... A někdo potřebuje chránit "pár kilo" klientského skriptu pro ovládání něčeho v prohlížeči (když logika aplikace jde bez problémů "schovat" na server)... Co zrovna na JS může být tak sofistikovaného a hodného ochrany? ;)
Tohle je nesmysl. Neochranis. Zadnej JS nikdy neni necim co by stalo za to chranit.
Jde vidět, že pánové jsou experti... ;D ne, fakt, proč je i v roce 2016 některými JavaScript vnímán jako "něco horšího", i když je to asi milionkrát vyvráceno?
K tématu: Obávám se, že pro stranu klienta to asi není úplně reálné. I kdybys něco našel, tak silně pochybuju o účinnosti takového řešení... Pokud mluvíme o node.js, tak tam už by třeba možná něco udělat šlo...
-
ntpt: vzhledem na to ze body 1. a 2. jsou nesmysl (je jedno v jakem stavu zdrojak das ven, proste ho das ven) tak bod 3. uz vubec nikto neresi. Jestli chces neco v JS schovat tak presun JS kod na server, pust ho v nodejs a browser at dynamicky natahne pouze vysledek. Tak nebo onak, jdes na problem zle a uz ti tu par lidi spravne napsalo, ze OBFUSKACI NERES nic tim neziskas, spise naopak.
-
Zadnej JS nikdy neni necim co by stalo za to chranit.
proč je i v roce 2016 některými JavaScript vnímán jako "něco horšího", i když je to asi milionkrát vyvráceno?
Ok. Asi jsem mel byt duslednejsi ve vysvetlovani. JS jsem bral jako tu vec co bezi u klienta v prohlizeci. Obfuskovat pripadnou serverovou asi neni predmetem dotazu. Na tom se snad shodneme.
No a pak tedy mame tu klientskou cast. Mas pocit, ze hodnota projektu jako twitter/FB spociva v jejich hustoprisne naprogramovanym frontendu? Mas pocit, ze potrebuji resit obfuskaci? NE. Logika je na serveru. Data tvori hodnotu ci "hodnotu" te spolecnosti. Mas pocit, ze jakekoliv prime bankovnictvi, paypal apod potrebuji obsufkovat JS? Nepotrebuji. Ten JS je mozna kvalitni programatorske dilo, mozna ma milion dalsich dobrych atributu, ale "ukrast" jej sam o sobe ma nulovou hodnotu. Nic s nim neudelas.
Vymyslis nejaky hustoprisny product designer pro nejaky eshop? Fajn, zajiste bude stat hodne penez, mozna privede spoustu kseftu. Ale kdyz ti ho "ukradnu" tak co tim ziskam? Neziskam tim zadne kvalitni fotky ani kvalitni popisy. Neziskam reputaci na trhu. Neziskam dodavatele zbozi a velkoobchodni slevy.
To byla pointa te "bezcennosti" takoveho javascriptu. Kdyz ho budu chtit zkopcit tak je mi jedno jestli copy-paste nebo zaplatim programatora. Know-how toho javascriptu je to co vidi klient a jake to ma UX. To je ta prava hodnota toho produktu a zaroven je to neco co nelze obfuskovat(leda to nevypustit mezi lidi).
Tak pred rokem tady byl takovej managor co si taky myslel, ze lze nejak zabezpecit jeho webovou databazi proti crawleru. NELZE. Nebo pri nejmensim NELZE EFEKTIVNE.
-
Jde vidět, že pánové jsou experti... ;D ne, fakt, proč je i v roce 2016 některými JavaScript vnímán jako "něco horšího", i když je to asi milionkrát vyvráceno?
Nepředvádíte náhodou "Podsunutý argument"? :) Nikde jsem nepsal/nepsali, že JS je něco horšího. S kolegou jsme psali, že JS na straně klienta v prohlížeči nemá zrovna cenu nějak zvlášť chránit. Já se dál "řečnicky" ptal, co za cenný algoritmus se v prohlížeči na straně klienta může skrývat. Revoluční kontrola formuláře bez odeslání na server?
Podsunutý argument (straw man)
Podstatou klamu je najít velmi slabý až hloupý argument, který by mohla zastávat protistrana (ale zpravidla jej nezastává). Ten demonstrativně rozcupovat na cucky a budit při tom zdání, že se všemi argumenty protistrany se lze takto snadno vypořádat.
-
Ne, nepředvádím, reagoval jsem na pejorativní vyznění vašich příspěvků. :) Pakliže to bylo myšleno pouze na klientskou část, tak pak dejme tomu ( i když i na frontendu lze "obšlahnout" pěkné a elegantní řešení). A to že tomu nejde zabránit neznamená, že to nemá cenu, ale ano, souhlasím, to hlavní bývá ve vámi uvedených případech na serveru (který úplně stejně dobře může také běžet na JS - tedy zde už by mohl být něčím, co má cenu chránit).
Ale jak říkám, pokud jste to myslel/i pouze na klienta, tak ok, beru. :)
-
Já se dál "řečnicky" ptal, co za cenný algoritmus se v prohlížeči na straně klienta může skrývat. Revoluční kontrola formuláře bez odeslání na server?
To autor nenapsal, ale kazdopadne lze provozovat single page web aplikaci, kde mate pouze index.html a celou logiku napsanou v JS a tedy v prohlizeci, stranky se generuji dynamicky. Klidne celou MVC aplikaci. Server pak servuje pouze data (treba pres REST) a ne stranky. V tom pripade samozrejme nejake algoritmy venku jsou a mozna by je chtel chranit ale je to prinicipialne nemozne protoze at je zdrojak jakkoli zamotanej porad to je jen program, ktery compiler browseru rozbali do neceho univerzalnejsiho. Volame to Abstract Syntax Tree. A tam sebelepe obfuskovanej alogoritmus se predvede v sve prostote a nahote rovnou jako vyvojovej diagram :)
Muzete se s tim pohrat i online treba tady http://resources.jointjs.com/demos/javascript-ast .
-
Na obfuskaci javascriptu bych si dal pozor. Když jsem pro jeden svůj web takhle znepřehlednil javascript, za pár dnů byl můj web veden jako infikovaný nějaký bordelem (i když nebyl) - zřejmě byl ten obfuskátor v minulosti použit pro znepřehlednění nějakého nebezpečného kódu. A výsledný skript na mém serveru jevil stejné patterny, takže byl můj skript podezřelý...
-
To autor nenapsal, ale kazdopadne lze provozovat single page web aplikaci, kde mate pouze index.html a celou logiku napsanou v JS a tedy v prohlizeci, stranky se generuji dynamicky. Klidne celou MVC aplikaci. Server pak servuje pouze data (treba pres REST) a ne stranky.
OK, ale většinou ta posílaná a zpracovaná data ze serveru bývají cennější než klientské ovládání aplikace. Navíc na serveru bude probíhat i logika aplikace. Nevadí, že se to děje přes REST, prostě na server se pošle nějaký vstup a získá se nějaký výstup (analogie nějaké přilinkované aplikační knihovny ke GUI). Na klientském JS zase zbude jenom klientské ovládání a v tomto případě i kompletní prezentace (oproti tomu, když to "předpřipraví" server v HTML). Pořád ale platí - co chci skrýt, nechám probíhat na serveru. A bez serveru je celá aplikace k ničemu. ;)
-
A bez serveru je celá aplikace k ničemu. ;)
Mozna je to Doom 5 v javascriptu ! 8)
-
to hlavní bývá ve vámi uvedených případech na serveru (který úplně stejně dobře může také běžet na JS - tedy zde už by mohl být něčím, co má cenu chránit).
No, ale pokud mam nejakou takovou cennou aplikaci tak prece nebudu zabezpeceni na serveru resit obfuskaci. Na to jsou uplne jine postupy.
-
to hlavní bývá ve vámi uvedených případech na serveru (který úplně stejně dobře může také běžet na JS - tedy zde už by mohl být něčím, co má cenu chránit).
No, ale pokud mam nejakou takovou cennou aplikaci tak prece nebudu zabezpeceni na serveru resit obfuskaci. Na to jsou uplne jine postupy.
Nemám pocit, že bych někde psal něco o tom, že bych to "řešil obfuskací". :)
-
Nemám pocit, že bych někde psal něco o tom, že bych to "řešil obfuskací". :)
Tak už to holt dopadá, když v dotazu chybí důležité věci a lidi si je domýšlejí.
Chybí odpověď na otázku "Proč?".
-
A bez serveru je celá aplikace k ničemu. ;)
Mozna je to Doom 5 v javascriptu ! 8)
Když už je v Javascriptu napsaný i emulátor x86, na kterým nabootuje linux (sic !) tak proč ne .o) http://bellard.org/jslinux/
-
Google Closure Compiler
-
Když už je v Javascriptu napsaný i emulátor x86, na kterým nabootuje linux (sic !) tak proč ne .o) http://bellard.org/jslinux/
Uzasne! Bogomips vychazi jen 26x pomalejsi. To vola po serverovem nasazeni.
-
Když už je v Javascriptu napsaný i emulátor x86, na kterým nabootuje linux (sic !) tak proč ne .o) http://bellard.org/jslinux/
Uzasne! Bogomips vychazi jen 26x pomalejsi. To vola po serverovem nasazeni.
Třeba v něm poběží i emulátor x86 napsaný v Javascriptu a kruh se tím uzavře.
-
Třeba v něm poběží i emulátor x86 napsaný v Javascriptu a kruh se tím uzavře.
Pokud naopak nedojde k nekonecne rekuzri...
-
V (de)obfuscaci se moc nevyznam, ale neni neco podobneho pro JS, jako v oblasti her? Tj. ze ochrana si v podstate provozuje vlastni VM, ktere se nahodne modifikuje a ze servru ziskava kusy kodu, ktery desifruje, zakomponuje a pousti na tom virtualnim stroji?
-
V (de)obfuscaci se moc nevyznam, ale neni neco podobneho pro JS, jako v oblasti her? Tj. ze ochrana si v podstate provozuje vlastni VM, ktere se nahodne modifikuje a ze servru ziskava kusy kodu, ktery desifruje, zakomponuje a pousti na tom virtualnim stroji?
Vetsinou se jenom vygeneruji absurdni jmena promennych, neco se prehazi, neco inlinuje, pokazi se formatovani...
-
V (de)obfuscaci se moc nevyznam, ale neni neco podobneho pro JS, jako v oblasti her? Tj. ze ochrana si v podstate provozuje vlastni VM, ktere se nahodne modifikuje a ze servru ziskava kusy kodu, ktery desifruje, zakomponuje a pousti na tom virtualnim stroji?
Vetsinou se jenom vygeneruji absurdni jmena promennych, neco se prehazi, neco inlinuje, pokazi se formatovani...
Jn, jasne. To je bezna minifikace, ktera se pouziva tedy spise kvuli rychlosti. To se snad ani neda povazovat za "obfuskaci", kdyz kazdy deobfuscator/beatufier nebo i hloupy dev tool v Chrome to zvladne celkem solidne narovnat do citelne podoby. Je to skoro jako kompilace zdrojaku v C++ ci Jave, kterou take nenazyvame obfuskaci, prestoze technicky asi take je.
Jsem prave mel na mysli neco pokrocilejsiho, kde je napr. primo v JavaScriptu naimplementovana vlastni virtualni masina s vlastnim siforvanym kodem, ktery se pri provadeni modifikuje a presifrovava a zadne spusteni neni stejne, prestoze vysledek to vyplivne stejny. V tom Denuvu se navic nejak pouziva unikatni desifrovaci klic generavoany podle seriovych cisel komponent v pc (klic je vytvoreny serverem) a zdrojak hry je prosety pastmi, kdy hra sice nespadne, ale zamerne se nejak lehce polame (napr. nedoplnovani hp, zamceni dveri, 5x vetsi damage od nepratel, pridani pasti, ktera instatne hrace zabije atp.).
-
Jsem prave mel na mysli neco pokrocilejsiho, kde je napr. primo v JavaScriptu naimplementovana vlastni virtualni masina s vlastnim siforvanym kodem, ktery se pri provadeni modifikuje a presifrovava a zadne spusteni neni stejne, prestoze vysledek to vyplivne stejny.
To by vyzadovalo "zamcenou" cast pameti co v browseru neni. Proste i dynamicky generovany JS kod se musi nasledne executnout a ty mas moznost videt co se prave provadi i pamet vsech objektu. Proste jakakoli obfuskace kodu nic neresi, protoze ty ho mas moznost videt jak bezi. I kdyby to cele bylo zasifrovane 4kilovym blowfishem tak se to nekde musi desifrovat a neschovas to.
-
Jsem prave mel na mysli neco pokrocilejsiho, kde je napr. primo v JavaScriptu naimplementovana vlastni virtualni masina s vlastnim siforvanym kodem, ktery se pri provadeni modifikuje a presifrovava a zadne spusteni neni stejne, prestoze vysledek to vyplivne stejny.
To by vyzadovalo "zamcenou" cast pameti co v browseru neni. Proste i dynamicky generovany JS kod se musi nasledne executnout a ty mas moznost videt co se prave provadi i pamet vsech objektu. Proste jakakoli obfuskace kodu nic neresi, protoze ty ho mas moznost videt jak bezi. I kdyby to cele bylo zasifrovane 4kilovym blowfishem tak se to nekde musi desifrovat a neschovas to.
A pri spusteni hry na pc snad muzes jadru nebo jinym ovladacum efektivne zakazat pristup do sve pameti? (Tak nizko OS jsem nikdy nedelal, takze fakt netusim.)
To, o cem pisu neni trapne "desifruj -> eval". Ale zjisti od servru (po overeni napr. auth tokenu a "unikatniho" fingerprintu prohlizece) unikatni klic a dalsi casti kodu, ktere nasledne vzdy chvili vykonavas a pak desifrujes dalsi cast kodu ve VM, nebo dostanes dalsi klic nebo kod. Nic nelze 100% zabezpecit, ale treba ten SecuRom nebo Denuvo to muze zatracene zpomalit (napr. mesice po vyjiti ocekavane AAA hry necracknute) a pokud je to unikatni ochrana, tak si kazdy dvakrat rozmysli, jestli se to bude snazit prolamovat, kdyz by bylo levnejsi si treba 10x zaplatit predplatne a napsat bota.
Ale stejne jako ve vlaknu o zabezpecovani mapy v JS - osobne silne pochybuju, ze OP ma tak ceny algoritmus, ktery musi bezet na klientovi a zaroven se vyplati jej takto chranit.
-
To, o cem pisu neni trapne "desifruj -> eval". Ale zjisti od servru (po overeni napr. auth tokenu a "unikatniho" fingerprintu prohlizece) unikatni klic a dalsi casti kodu, ktere nasledne vzdy chvili vykonavas a pak desifrujes dalsi cast kodu ve VM, nebo dostanes dalsi klic nebo kod.
Jenze browser nic jineho nez JS neumi spustit. I kdyz si tam implementujes proprietarni jazyk ci celou VM tak se to musi decodnout do JS a ten spustit. A to neschovas, jenom udelas zlozitejsi. V podstate tve definici vyhovuje treba takovej React ale na konci je porad plain JS, ktrery se spousti.
-
To, o cem pisu neni trapne "desifruj -> eval". Ale zjisti od servru (po overeni napr. auth tokenu a "unikatniho" fingerprintu prohlizece) unikatni klic a dalsi casti kodu, ktere nasledne vzdy chvili vykonavas a pak desifrujes dalsi cast kodu ve VM, nebo dostanes dalsi klic nebo kod.
Jenze browser nic jineho nez JS neumi spustit. I kdyz si tam implementujes proprietarni jazyk ci celou VM tak se to musi decodnout do JS a ten spustit. A to neschovas, jenom udelas zlozitejsi. V podstate tve definici vyhovuje treba takovej React ale na konci je porad plain JS, ktrery se spousti.
To ja nikdy nepopiral. Stejne tak SecuRom nebo Denuvo je porad spousteny na realnem procesoru, kde snad take lze trackovat instrukce, a presto je to ucinna ochrana (relativne receno - nebyla prolomena mesice, coz na pomery hernich ochran je neuveritelne dobre skore). Jde o to, ze tam pridavate dalsi vrstvu - sebemodifikujici se dynamicky spousteny kod, ktery staticky nemuzete cely ziskat - jednoduse proto, protoze nemate vsechny casti a ruzne casti jsou sifrovany ruznymi klici (generovani casti i klice se ziskavaji ze servru kdyz je potreba, nelze si vyzadat vsechny; navic dane casti funguji jen pro dany klic prohlizece, jinde spusti pasti).
Mate pravdu, splnuje to asi i ten React (detailne neznam) i Angular. Asi stejne tak, jako ze sifrovaci algoritmus je Caesarova sifra. Rozdil je v tom, ze v pripade Angular aplikace si muzete hromadne stahnout vsechny sablony (casto jsou predkompilovane primo v js) a casto je cela aplikace jeden bundle, takze mate cely zdrojak v cistem JS, staci najit funckci, ktera dela vypocet. V pripade te hypoteticke ochrany mate kusy sifrovaneho kodu, ktery je vam na nic, protoze potrebujete vsechny kusy a klice pro vsechny kusy (rozkouskovani i klice mohou byt dynamicke, takze pokud vam v polovine grabovani server zasle nove vm, tak jste v haji a muzete zacit od znova). Navic kdyz je to sebemodifikujici se, tak musite i simulovat ten VM a prolomit generovani toho "unikatniho" klice pro prohlizec, jinak to bude nahodne davat spatne vysledky na jinych prohlizecich/strojich. Je rozdil dekodovat par kilobajtu minifikovaneho JS, kde vim, ze tam nekde asi bude ta "zlata" funkce versus dekodovat par megabajtu kodu VM, kde casti jsou obsluzne veci VM, casti samotny zasifrovany kod vevnitr a dalsi casti data toho VM (pripadne oboje zaraz). Pokud jsou napr. nektere veci pouzivane ve vice formach (rozsiforvane i zasifrovane), tak napsat nastroj, ktery to automaticky deobfuskuje nebude trivialni snapshot ast v prohlizeci. Bude se muset celkem dlouho sbirat klice a kusy kodu, zjistovat, jak je davat dohromady (vm muze server zaslat nove, ktere nebude mit stejnou podobu provadeneho VM kodu, klidne muze byt ten jeden algoritmus implementovany nekolika zpusoby, coz razantne prodlouzi prolamovani). Dalsi vec je, ze musite take identifikovat vsechny trapy (coz je vetsinou nerealne) nebo rozlousknout, jak se generuje ten prohlizecovy klic.
Chapu, proc nikdo takoveto slozite ochrany v prohlizeci neresi. Proc to resit na strane klienta, kdyz to bude neuveritelne drahe, pomale (na mobilech nepouzitelne) a nikdy ne 100%, kdyz to lze trivialne resit na strane servru za zlomek ceny a bude to rychle jako blesk.
Jako uznavam, ze je zajimave se nad tim zamyslet, ale zodpovezeno to bylo uz na zacatku vlakna.
@OP presun ten vypocet na server a neres kraviny.