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.
35 Odpovědí
10117 Zhlédnutí