Vlákno názorů k článku
Všechny velké prohlížeče už podporují WebAssembly
od Diskobolos - Slova skript a bytecode v prostředí webu/prohlížeče mě...
-
j (neregistrovaný)
Nevim jak Diskobolos, ale za me tohle zarizujou addony (jo, vim ze pro chrofox je to sprosty slovo). A nektery konstrukce v js jednoduse znamenaj, ze ten js odstreli celej.
Nemluve o tom, ze do citelnyho scriptu se maketaci a dalsi zvirada neodvazej dat zdaleka takovy hruzy, jaky vecpou do necitelny binarky.
A mluvi o bezpecnosti prohlizece ...lol ... odesilani polohy, stavu akumulatoru, idektifikace HW, primej pristup k GPU, ....
-
strepty (neregistrovaný)
Ale je aj bytecode. Vo Windows existuje managovany a nemanagovany C++, ten prvy ma bytecode ten druhy nie a skompiluje sa na strojovy kod. Nic to nemeni na tom ze nikto nema potuchy co je v kode telemetrie napisane, ci uz je to kod managovany alebo nie. Kazdy velky soft pod Windows je teraz pisany v managovatelnom kode a nemate sancu vykradnut ich napady lebo to je zlozite.
-
Aha, ty mluvíš o obskurním managed C++. Tak to tě mohu uklidnit, to se tohoto článku netýká, snad tě zmátlo, že je tam použito slovo bytecode.
A obecně - ani kompilace do strojového kódu ani do bytecode není obecně žádnou zárukou toho, že tomu nikdo neporozumí. To že jsi to nepochopil ty neznamená, že to nedovede nikdo další, není to ekvivalentní jev.
-
strepty (neregistrovaný)
"obskurním managed C++. " ak sa Vam nepaci managovane C++ (neviem preco obskurne, bezne sa pouziva) co budete robit ked uvidite C kompilatory pre WebAssembly.
Nie nepisal som o sebe. Ja som pisal ze nikto nevykradol napady v kodoch a z toho som vyvodil ze kody nikto nevedel rozlustit. Alebo poznate konkretny opak spetneho inzinierstva? -
Pokud se běžně používá, tak máš patrně na mysli C++/CLI?
Co myslíš tím "vykrást nápady v kódech"? A jak víš, že to nikdo neudělal? Konkrétní opak zpětného inženýrství najdeš na jakémkoli warez fóru. Je běžné, že populární programy s komerční ochranou jsou cracklé během pár dní a to se nejedná o managed, ale stroják, kde je přímo záměr, aby to cracknout nešlo. Vypadá to, že máš poněkud přehnané představy o složitosti kompilovaného kódu.
Mimochodem čas od času se hrabu ve strojáku x86, není to pro každého, ale ani to není nepřekonatelné. Proti tomu je dekompilace .net nebo JVM bytecode vyloženě triviální. A wasm nebude o nic složitější. -
strepty (neregistrovaný)
"cracknout nešlo" Napriklad taky Windows 10 som este craknuty nevidel. Najst jednu podmienku a prepisat ju na negaciu je jedna vec a zistit ci v kode nie je napriklad trojsky kon je vec uplna ina. Oproti tomu vykradnut funkciu napriklad na doostrenie obrazka musi byt hracka, keby to zistili autori tak by boli sudy a bolo by okolo toho halo, ale take veci sa nedeju, a moj osobny nazor je ze taku uroven porozumenia kodu uz ani ludia nedosiahnu.
-
lol2 (neregistrovaný)
nerob zo seba sasa ked tomu nerozumies. Svojho casu ked sme pravadzkovali privatny wow server tak sme cez IDA disasemblovali wow.exe a hladali v nom ako v blizzarde poprehadzovali bajty v response packetoch.
Neviem co do toho tahas nejaky windows 10? Ostatne zrovna crackov na windows najdes 4 prdele a mozes si rovno vybrat ktorym smerom prdele to chces cracknut.
Za dalsie - heuristika ti asi nic nehovori, pritom sa v AV pouziva dobrych 30 rokov. WASM bude pouzivat nejake API ktore ma jasne definovane metody a to vsetko sa da detekovat.
-
strepty (neregistrovaný)
" lol2 Svojho casu ked sme pravadzkovali privatny wow server tak sme cez IDA disasemblovali wow.exe a hladali v nom ako v blizzarde poprehadzovali bajty v response packetoch."
Takze po pozreti kodu v IDAe pre wow.exe dokazete povedat na 100% ze tam nemaju trojskeho kona? Ona to je celkom relevantna otazka ked pracujete vo firemnom prostredi a chcete zaistit aby sa citlive informacie nedostali von. Windows 10 pouzivam ako priklad ktoremu na admin fore kazdy rozumie, napriklad ja o wow.exe nemam ani tucha ( a je pre mna dost divne ze by komunikacia bola v exe subore a nie v dll ale asi to tak je ked to poviete ). Inak ak mate funkny crack na win10 tak dajte link. ja taky nepoznam. Ale myslim taky ze neprestane fungovat po pol roku. -
j (neregistrovaný)
2Karell: Ty netusis naproto vubec co to je byt deterministicky ze?
Deterministicky (vetsinou) neni ani preklad ze zdrojaku do binarni podoby. Existuju (velice vyjimecne) prekladace, ktere deterministicke jsou = stejny zdrojak da vzdy exaktne stejnou binarni podobu. V drtivy vetsine pripadu to neplati. Uz jen proto, ze kompilator provadi vsemozne optimalizace na zaklade okolniho kodu.
Zpetny preklad neni deterministicky NIKDY. Neexistuje zadny zpusob jak z binarniho tvaru ziskat zpet originalni zdrojovy kod. Existuji jen zpusoby, jak vygenerovat kod, ktery (v idealnim pripade) dela totez. Pricemz toho vygenerovaneho kodu kldine muze byt i neakolikanasobne vice, nez puvodniho zdroje, potazmo i naopak, ale to by opet byl spis extrem.
Tudiz zvanis o vecech, o kterych nic netusis, ani paru nemas, bez se zeptat crackeru, proc nekdy trva mesice neco cracknou, dyk to prece neni zadnej problem, proste vemu binarku, z ty si vygeneruju zdrojak, a v nem si prectu co kde zmenit, trivka ne?
-
K těm velice vyjímečným překladačům můžeš studovat zde
https://wiki.debian.org/ReproducibleBuilds
Jak vidíš, běžné gcc umí zhruba 20k balíčků reprodukovatelných.Pokud si myslíš, že optimalizace implikuje nedeterministický překlad, tak jsi stále ještě nepochopil význam slova "deterministický".
Už se poněkud opakuji, výrazy "deterministický překlad" a "stejný zdroják jako originál" nejsou ekvivalentní.
Já nikde netvrdil, že někdy crack netrvá měsíce ani jsem netvrdil, že se to dělá přes dekompilaci. To je poněkud zvláštní vedení diskuze vymyslet si výroky a ty pak vyvracet.
-
KateStříbrný podporovatel
Takže maintaineři debianu lžou… Prosímtě, jdi jim vysvětlit že snaha o Reproducible Builds je nesmysl a vlastně jim to nefunguje, i když jim to funguje.
-
To jen ten nedostatek vzdělání :(
Deterministický algoritmus má při stejném vstupu vždy stejný výstup. Příkladem může být nahrazení písmene "A" za písmeno "B" v daném textu. Nedeterministický algoritmus je například takový, který náhodně (i když dělat cokoliv skutečně náhodně je u počítačů trochu problém) vybere písmeno "A" v daném textu, a nahradí ho za písmeno "B".
https://cs.wikipedia.org/wiki/Deterministick%C3%BD_algoritmusKdyž vezmete daný bytecode a proženete ho daným dekompilátorem, tak bude výsledek vždy stejný. Je to tedy deterministický proces.
To máte zřejmě na mysli je problém analýzy chování programu. Strojový kód i řada jazyků umožňují konstrukce, u kterých se obtížně dokazuje, že nějaké věci nedělají. Příkladem může být kód, který modifikuje jiné části kódu (dopředná modifikace). Když chcete zjistit jestli kód nevolá řekněme funkci pro formátování disku, tak ji v kódu nenajdete, ale ona se tam může dostat v průběhu provádění programu, což se analýzou kódu zjišťuje velmi špatně. Řeší se to sandboxingem, kde se kontrolují akce prováděné programem během jeho provádění. Další možnost je použít nějaký jazyk, který neumožňuje použít nebezpečné konstrukce. Typicky je to C# a java, méně typicky různá rozšíření jazyka C. A i bytecode bývá typicky navržený tak aby neumožňoval nebezpečné konstrukce, a aby se dal relativně snadno analyzovat. Nezapomínejte také, že z funkčního hlediska je bytecode shodný se zdrojákem (v tom je princip překladu).
-
Karel (neregistrovaný)
Ne, bezpečnost bude znatelně horší. Nyní musel Javascript projít překladačem v prohlížeči. Nově dostane interpret už připravený bytecode. Rozdíl je v tom, že v interpretu jsou nepochybně chyby, díky kterým lze docílit změny chování. Pokud vám bytecode generuje překladač, tak řada z těch chyb nebude problém, protože překladač bude generovat validní bytecode. Pokud ale mohu dodat přímo bytecode, tak ho můžu upravit tak, aby se některá z chyb projevila.
Jinými slovy - interpret bude stále stejně děravý, ale díky tomu, že mohu obejít překladač, je snažší ty díry zneužít. Ubyla nám prostě vstva ochrany tvořená překladačem.
Ostatně Java na tom byla zpočátku (vlastně docela dlouho) stejně. Zkuste se podívat, kolik tam bylo potřeba záplat na chyby "java bytecode vulnerability". Vypadají například takto:
"An attacker can create a new instance of an object without calling the proper initialization method from within the constructor of the created class. This allows an attacker to bypass security checks performed by the Bytecode Verifier to create an instance of a Class Loader object. These objects can be used to allow an untrusted applet to obtain read- and write-access to the local file system or to crash Internet Explorer."
