 Mein Name ist Claremontine Maurice und das ist Daniel Gruß. Wir werden euch unsere Arbeit präsentieren über die Cash-Attacken von Rohammer. Ein paar Worte über uns. Ich habe gerade meinen PhD fertig gemacht, das ist eine Dissertation. Sie ist aus Rennes in France. Ich bin aus Deutschland, lieber in Österreich seit mehreren Jahren. Ich habe meinen PhD-Studium in Graz studiert und ich habe auf Cash-Attacks und Rohammer studiert, speziell heuer und habe sie auf alle auf meinem Laptop gefunden. Das ist die Geschichte Bitfrips im DRAM, Bitkeeper im DRAM. Es hat alles vor einem Jahr angefangen mit dem Paper Flipping Bits in Memory, wo sie gesagt sind, das ist der originelle ursprüngliche Rohammer Bag. Es war grundsätzlich, wurde das angesehen, als ein Verlässlichkeitsproblem. Und die Security Community hat gesagt, das ist vielleicht nicht so eine gute Idee, wenn ein Bit gibt, ohne dass man es korrigieren kann, während andere gesagt haben, naja, es sind ein paar Bitfripper. Wir können sie nicht kontrollieren, was soll da schon passieren. Eigentlich kann ganz viel schief gehen. Marc Simon hat das gezeigt und Hover Flake. Die haben zwei Exploits über diesen Rohammer gebaut. Das Sandbox Ausbruch und einen Exploit. Daniel hat im April begonnen und Rohammer Clementin hat ihn in der TU Graz dort gejoint. Wir haben auf Ivy Bridge den ersten Bitfripper zusammengebracht. Wir haben eigentlich ein paar Wochen später mit einer Injektion von JavaScripts die ersten DRAM Flips zusammengebracht. Das ist ein DRAM Module. Schauen wir uns einmal an, wie das organisiert und aufgebaut ist intern. Zum Beispiel, wenn du zwei Demodule hast und du zwei Kanäle, Kanal 0 und Kanal 1, gibt es vorne und hinten, die nennt man Franks, auf den Franks sitzt 8 Chips. Innerhalb eines einzelnen Chips hast du eine 8 Reihen mit jeweils einem Row Buffer. Wir werden uns nicht auseinandersetzen, wie das tatsächlich implementiert ist. Wir können nur Reihe durch Reihe zugreifen. Das DRAM wird selber seinen Activate Befehl absetzen und so, wie das DRAM designed ist, sind die Zellen undicht. Man muss es refreshen, um die Charge wieder zurückzubringen, damit wir keine Datenverlust haben. Diese Zellen liegen schneller, als ihr Access möglich ist. Das führt zum sogenannten Rohammer Bug. Motherboard, weil es hat das wunderschöne Vorführer, ist so, ich breche in ein Apartment ein, indem ich die Nebentür des anderen Apartments so lang zuwerfe, bis der Schüterungen die erste Tür öffnen. Also werden wir uns jetzt im Detail anschauen. Wir kopieren jetzt die Activate Commands in die Reihe hinein. Wenn wir diese Reihe auf diese Reihe zugreifen, müssen wir eine zweite Reihe aktivieren und dann wieder diese Reihe in die und her und dazwischen hast du deine Bitflips. Wir haben diese nicht angegriffen, und trotzdem sind sie geflippt, einfach, weil sie benachbart sind mit den beiden, auf die wir zugegriffen haben. Wir können auf Daten im DRAM nicht einfach so zugreifen. Du hast den CPO Cache dazwischen zwischen dem DRAM Cache, wenn wir den DRAM Overflow haben, wird es in den Cache gehen. Wir brauchen einen Non-Cache Access und alle anderen Nutentil-Fleusch-Instruction. Also tatsächlich diese Instruktion, die schiebt eine Nachricht vom Cache rein in den Rahmen, das heißt, diese nächste zugeführt dann vom DRAM kommen. Jetzt kurz ein bisschen Hintergrund über den Cache, weil das ist tatsächlich wichtig für den Rest des Talks. In modernen Prozessor-Architekturen haben wir mehrere Kernes, also sagen wir mal vier. Wir haben eine Hierarchie verschiedener Level von Caches. Level 1 und Level 2, die jeder Cache selbst hat, das heißt nur Kern 0 kann nur den Level 1 und Level 2 Cache von sich selbst benutzen, aber nicht den von Kern 1, 2 oder 3. Und dann haben wir den Last Level Cache, der auch aufgeteilt ist, aber diese Teile werden geteilt zwischen den verschiedenen Prozessor-Kern. Das heißt, einen Prozessor-Kern kann auch die Teile des anderen Prozessors zugreifen. Auch wichtig ist, dass dieser Cache die Eigenschaft hat, dass er inklusiv ist. Das heißt, dass alle Daten, die im Level 1 und Level 2 Cache ist, die sind also auch in diesem Cache mit drin. Okay, schauen wir uns mal den Rohammerangriff an. Wir haben also noch zu der Derambank, die wir haben, haben wir auch noch zwei Mengen an Caches. Und es gibt eine fixiert definierte, festdefinierte Verbindung zwischen den physikalischen Adressen und den Caches. Das heißt, wenn wir also die Daten schon im Cache haben, müssen wir nur diese Flash-Anwendungen aufrufen, Flasch, Entschuldigung, dann ist es weg und dann laden wir das neu und dann laden wir die anderen Adressen neu, dann flaschen wir sie wieder, laden wir sie neu, Flaschen, Reload, Flasch, Reload und ein Bitkipper, großartig. Und bevor ich jetzt weiter mal die Rohammer mache, spreche ich noch kurz über eine weitere Angriff. Und zwar Flasch und Reload habe ich jetzt besprochen gerade und das ist eine sehr mächtige, genaue Cache-Attacke und wir können damit sehr, sehr viel machen mit diesem Angriff und das funktioniert genauso wie ich es gerade beschrieben habe. Aber anstatt dass wir die ganze Zeit einfach nur zuschlagen, messen wir, ob tatsächlich ein Zuge vom Cache kommt oder ob es ein Cache missmacht und damit war und damit vom Deram kam. Und das kostet ein kleines bisschen andere Zeit und deswegen näcken wir das. Wenn wir das mit einer Shared-Libraries machen, dann können wir tatsächlich andere Prozesse beobachten, weil diese anderen Prozesse haben möglicherweise Methoden mit der Benutze-Eingabe zu arbeiten und dann sehen wir, wenn der Code aus dieser Shared-Library in den Cache geladen wird und wir haben ihn nicht in den Cache geladen, also als jemand anders gemacht, also war das wohl User-Input, also Benutze-Eingaben. Dann können wir diese Angriffe automatisieren. Wenn wir also jemanden haben, den wir beobachten wollen, dann können wir das alles automatisieren. Wir müssen das gar nicht von Hand machen. Das heißt, wir können Kryptoschlüssel, Key-Loggers benutzen. Wir können sogar über mehrere virtuelle Maschinen hinweg übersetzen. Okay, so. Was wir gerne machen würden, diese Roham-Attacke, ohne Seelflasch in Javascript, die wir gerne die Seelflaschbefehl vermeidet, das ist eine ganz spezifik in AD6, die wird es in keiner anderen Artikatur haben, außer in X86, und das ist auch abhängig vom Javascript. Also wir erweitern unsere Möglichkeiten, ohne dass wir mit Seelflasch arbeiten. Unser Approach ist ganz normalen Regular Memory Access für Cache-Lehrung. Das liegt allen Cache-Attacken zu Grunde. Den Cache leeren und wieder so, lass uns das verwenden, und es funktioniert auch hervorragend. Es funktioniert immer noch dem selben Prinzip, immer noch diese Bitflip in der Mitte, den wir erzeugen wollen. Also wir greifen verschiedene Adressen auf Cache-Set 1 und Cache-Set 2, bis wir den Lein völlig vollkriegen. Was jetzt hier wichtig ist, während wir uns aussuchen können, in welchen Cache-Set wir sie hinschreiben, aber die Repression Policy wird nicht von uns, sondern vom DRAM gemacht, so wir müssen einfach warten, bis wir das Richtige haben. Wenn der nächste Access Zugriff von DRAM erfolgt, wir tun das immer und immer und immer wieder, bis wir unseren Bitkeeper bekommen. Ohne den Seelflasch-Instruction von Javascript. Es gibt ein paar Herausforderungen. Wie kriegen wir diese physikalische Adresse im Javascript? Das ist eine Sandbox. Welche physikalischen Adressen müssen wir adressieren? In welcher Reihenfolge? Und wie kriegen wir das im Timing mit dem Javascript im einen Gemeinden? One does not simply throw hammer. Lass uns über das erste Problem. Physikalische Adresse in die DRAM-Zelle, da ist eine FIX gemapped, auf die DRAM-Sells, aber es ist natürlich nicht dokumentiert von Intel für verschiedene Gründe. Baxibon hat das Reverse-Engineered für Sandy Bridge Reverse-Engineered und wir haben dieses Reverse-Engineered fortgesetzt für ein Sandy, Ivy, Houseworld und Skylake in verschiedenen Konfigurationen. Was euch vielleicht aufgefallen ist, die erste Reihe wird als Cache eingesetzt. Accessing braucht eine verschiedene Zeit je nachdem von welcher Reihe es genommen wird und wenn sie weiter entfernt ist, gibt es mit einer weiteren Attacke einen anderen Explorer, der über die Zeit läuft. Aber lasst uns bei den physikalischen Adressen bleiben. Jetzt wissen wir das Mapping vom DRAM-Zelle, aber wir wissen nicht die physikalische Adresse, die der Javascript dort hineinschreibt. Das OS will immer alles optimieren und eine optimierungsmögliche 2-Mega-Bad-Pages sind effizienter. Da brauchen wir weniger TLB-Entries. Du kannst Physical Entries in TLB um die virtuellen Adressen zu übersetzen. Wenn du 2-Mega-Bad-Pages verwendest, kommst du darauf, dass die lasten 21-Bit, also die 2-Mega-Bad, der physikalischen Adresse und der virtuellen Adresse ident sind. Jetzt kommt die Melloc Implementation. Das ist eine gute Idee. Wir werden große Bereiche memory zu allokaten. Ja, das System sagt, wir brauchen 2-Mega-Bad. Ah, und wir haben die lasten 21-Bit in Javascript dort. Klar stehen. Was wir auch noch kriegen, ist, dass wir mehrere DRAM-Reihen pro 2-Mb-Page haben. Das heißt, wir wissen, dass wir einige Reihen haben, die wir jetzt mit dem Hammer bearbeiten können. Und wir haben einige Rows im Cache auch. Das heißt, wir können Eviction her betreiben. Wenn wir also noch nicht genügend congruente Adressen haben, dann können wir die Zeit-Information dort zumindest nutzen, um diese Information herauszufinden. Wir können auch Timing-Angriffe durchführen, um ohne diese 2-Mb-Pages zu arbeiten, und zum Beispiel mit 4-KB-Pages. Aber da brauchen wir mehr Zeit dafür. So, die nächste Frage ist, welche physikalischen Adressen müssen wir angreifen? Das nennen wir LRU Eviction, weil wir übrigens die LRU Replacement Policy. Das ist genau das, was ich Ihnen schon vorher gezeigt habe. Wir schauen uns also in Adressen vom gleichen Cache-Set an, um praktisch in Adressen auch aus dem Cache rauszuwerfen. Das ist sehr bekannt in den Cache-Attacken. Und wir nennen das, habe ich jetzt nicht mitgekriegt, jetzt haben wir diese Eigenschaft des LRU, dass das ja inklusiv ist. Und was das heißt ist, dass wenn wir eine Zeile aus dem LRU herausnehmen, dann wird es aus der gesamten Hierarchie der Cache herausgenommen, um diese inklusive Hierarchie zu garantieren. Wenn wir also eine Zeile aus dem LRU evikten herauswerfen, das klingt einfach, aber tatsächlich so einfach ist es gar nicht. Wir müssten nämlich sehr genau wissen, die Adressen und wie sie zugeordneten sind im Cache. Für den LRU-Cache müssten wir also wissen, in welchem Slice, in welchem Abschnitt diese Adresse zugeordneten ist. Und es gibt in den Intel-Prozessoren eine Herrschfunktion, die die physikalischen Adressen zu Slice zuordnet. Aber und die ist auch von Intel dokumentiert. Das heißt, glücklicherweise haben wir, kurz bevor wir in Graz angekommen sind, oder bevor ich in Graz angekommen bin, habe ich genau diese Herrschfunktion reverse-engineered und habe es tatsächlich geschafft. Und da war da nicht alleine dabei, sondern es gab noch andere Teams, die daran gearbeitet haben. Und wenn ihr die dreckigen Details wissen wolltet, dann schaut euch diese Papers an. Fun fact, diese Herrschfunktion ist grundsätzlich ein Exor von Adressbeats. Und die nennen es eine Herrschfunktion. Okay. Auf der Replacement Policy auf older CPUs LRU Eviction ist ein Mappen zum selben Cache Set. Und wir werden uns das kurz nochmal anschauen nachher. Die LRU Replacement Policy sagt, die ältesten Anträge zuerst, wir brauchen eine Timestamp für jede Cache Line. Wenn wir irgendeine Adresse zugreifen, vielleicht ist es schon im Cache und die Timestamp ist updated. Wenn wir in Zeitung für einen Endzeit-Set und wenn wir das sichergehen, dann haben wir die Targetadresse gelöscht. Auf jüngeren CPUs ist das nicht mehr so. Sie haben keine LRU Eviction Polices. Wenn du das auf einer neuen CPU verwendest, tut das aber, das willst du nicht. Aber das geht zu weit für diesen Talk. Was ich sagen kann ist, auf Haswell haben wir nur 75% Erfolg, wenn wir LRU Eviction verwenden. Wir können more Accesses verwenden und gegen einen höheren Erfolgsrate, aber wir werden zu langsam. Es würde für die Cache-Attacks wagen, aber für Rohammering ging es nicht mehr. Wir müssen uns dafür überlegen, wie wir den Cache dazu kriegen, die Adresse früher rauszuwerfen. Eine Strategie, das zu tun, ist dieses Methode. Wir access Adresse 1, dann 2, 3, dann wieder 1, dann 2, dann 2, 3, dann 3 und 4, 4. Wenn wir dieses Pattern verwenden, mit diesem Pattern gehen wir auf Haswell und auf Ivory Bridge auch eine relativ faste Eviction Rate und mit dieser Strategie kriegen wir über 99,97 Data Eviction und damit können wir wieder Rohammern. Bleibt eine Frage über. Wie kriegen wir das Timing im JavaScript hin? Ich brauche das für zwei Dinge. Das eine, ich muss den Native Code im RTD, wenn wir nicht genug konkurrieren, der Adressen auf das einzelnen Page haben und zweitens müssen wir uns entscheiden, ob die Adresse jeweils gecached ist oder nicht. Ich muss validifizieren können, ob die Eviction successful war oder nicht. Im Native Code ist das einfach. Du sagst auch, RTD SC, du kriegst einen Time Set. In JavaScript ist etwas komplizierter, aber Winter Performance now und das ist perfekt und du kriegst deine Exises raus. Dann hat es einen JavaScript gepatched, die können in JavaScript Maus Movements verwolten, die haben das gemacht, abrunden gegen auf 5 Millions Exises. Das funktioniert aber nicht bei Rohammer, weil wir sind immer noch um ein Faktor 5 schneller. Unsere Evaluierung, der Bitkeeper Rate auf der Testmaschine mit dem Haswell, während dieser Evaluerung, wir haben die Refresh Interval variiert, der Default ist ziemlich low, niedrig und das Maximum ist die Maximum Refresh Interval. Was wir hier sehen können, gibt es einen Punkt, wo die Bitflips auftreten für einen Sealflash von Native Code Eviction. Ungefähr gleich. In der Eviction Variante, in der Sealflash Variante, in der JavaScript Variante müssen wir etwas höhere Eviction Interval nehmen, weil JavaScript offenbar etwas langsamer ist als Native Code. Das ist also die Anzahl an Bitflips innerhalb von 15 Minuten. Wenn wir die Eviction Strategie benutzen, sogar bei einem höheren Refresh Interval haben, dann haben wir mehr als 10.000 Bitkippen, das sind also mehr als 10 Bitkippen pro Sekunde, abhängig von eurer Maschine, funktioniert es genauso gut oder ein kleines bisschen schlechter, das hängt von der Hardware an, ab von eurem System eben. Was uns mal über den Exploids sprechen, wie können wir da Exploids daraus bauen? Die erste Idee, die wir hatten, war, wir könnten diesen Root-Explos einfach mal nach JavaScript portieren und das könnte sogar funktionieren. Wir haben das noch nicht abgeschlossen, aber es sollte funktionieren. Und der Exploid von Marc Sieborn, der macht PageTable Springs, also du füllst den Gesamtspeicher mit PageTables und wenn du dann einen Flip hast, dann kannst du plötzlich deine eigenen PageTables damit bearbeiten. Und dieser Exploid braucht geteilten Speicher, das heißt, weil wir die Pages eben nicht schreiben wollen, sondern die PageTables und den haben wir normal, diesen geteilten Speicher, den haben wir nicht in JavaScript. Aber zum Glück haben wir früher dieses Jahr beobachtet, als wir auf einen anderen Paper gearbeitet haben, dass zero Pages dedupliziert werden normalerweise in JavaScript. Das heißt, wir haben eine Art Shared Memory in JavaScript. Das ist natürlich schlecht. So. Der physikalische Speicherzugriff im nativen Code, wenn wir da einen Exploid von wollen, dann finden wir einen ausattackierbaren BitFlip und ein Address-Bit, das aus-exploitbar ist. Und dann lassen wir die, dann releasen wir die BitFlip, die BitFlip-Page los und dann tun wir da eine neue PageTable genau dahin schreiben, indem wir ganz viele, viele neue Pages alloziieren und danach versuchen wir den BitFlip nochmal auszuführen. Und dann probieren wir einfach nur, ob der BitFlip erfolgreich war, ob wir also ein PageTable an dieser Stelle haben und den ja, dann können wir diesen PageTable modifizieren und schauen, wo in unserem Address-Raum ist eigentlich interessante Daten. Wenn wir dasselbe mit JavaScript machen wollen, würden wir zero Pages benutzen und zero Pages sind leider nur Lesen nicht schreiben. Das heißt, wir müssen tatsächlich zwei Sachen an dieser Art an diesem Angriff ändern. Wir müssen also auch das Schreibbar-Bit flippen, kippen. Und das ist viel schwieriger, weil das Schreibbar-Bit ist natürlich in einer bestimmten Position und wir haben nur einen einzigen und nicht verschiedene. Und die andere Sache ist, die wir ja noch ändern, ist, wir leben überall zero Pages anstatt digitalen Pages. Das habe ich auf meiner Maschine probiert und es ist möglich, so einen BitFlip zu finden, aber die sind deutlich seltener als andere BitFlips. Okay. Code execution as a root. Code Ausführung als root, wenn wir das haben wollen von unserem vollen Zuguf auf den Speicher, das ist dann relativ einfach, weil wir können nach einer Page einer bekannten Binary suchen und dann den ändern, so dass die Shellcode ausführen kann. Und diese Page wird ziemlich sicher nicht aus dem Speicher geworfen, weil wir haben einen großen Datei-Cache in unserem Betriebssystem und das heißt, wir warten einfach nur bis der root benutzt und dann den Shellcode ausführen und dann können wir alles tun auf unserem System. Jetzt haben wir eine nette Attacke, jetzt brauchen wir da keine Lösung. Das Erste, was einem einfällt, wir sollten die BitKeeper vermeiden, das ist eine Hardware-Frage und die Hardware-Resourcen-Entwickler, sie arbeiten dran, die Idee dahinter, dass man die reinrefresht, bevor die BitKeeper auftreten. Also eine smartere Weise diese Roan, man kann die Hardware nicht patchen, das heißt, dass er selbst, wenn sie eine Lösung finden, wird das nur für die neue Hardware sein. Die Liege, sie haben, wird weiterhin angefangen. Auf dem Rohhammer wird vor allem alte Hardware-Vendors angreifen und das wird noch ein paar Jahre vorhanden sein. Die zweite Idee ist das BIOS-Patchen, das etwas einfacher, etwas simpler, wir einfach erhöhen die Refresh-Rate, üblicherweise die Rate verdoppeln. Das ist für alle Maschinen vielleicht nicht ausreichend, braucht ein BIOS-Update, das ist das zweite Problem. Wer macht das? Ja, wer, aber von den Usern, wer macht ein BIOS-Update? Hatten wir eine andere Idee. Eine Idee, die hatten, die wir da fröhlich dahin gehämmert sind ist in Ordnung, nothing is perfect. Wir haben uns, wenn wir sagen, ist uns eigentlich ganz egal, versuchen wir nicht einfach den Privileges-Level gleichhalten, wenn wir im Us-Patchen und dann können wir vom OS her die Rohhammer-Experts verwenden. Rohhammer wäre in Ordnung so zu sagen, solange es keinen Explorer ausgibt. Da gibt es physikalische Memory-Post, da werden unterschieden mit Pages, mit verschiedenen Access-Privileges. Das klingt ziemlich mühsam, aber wenn man ein bisschen darüber nachdenkt, könnte es funktionieren, wenn man sich vor allem in die Privileges einarbeitet und man könnte dann nach wie vor mit wenig Zwischenraum und Memory-Post arbeiten. Nun zur Zusammenfassung. Cash-Lehrung ist schnell genug und CL-Flash damit ist es unabhängig von Low-Level Instructions und welcher Sprache. Wir können das jetzt überall verwenden am Smartphone, Arm, Chips. Das ist der erste Hardware-Fold für Javascript. Auch der erste Hardware-Attack durch eine Remote-Website. Es ist ein bisschen mühsam über eine Remote-Website. Ja, ja, wenn ich eine Website habe und jeder, da kommen eine Million User drauf, dann wird das auch, wir sind noch nicht dort, aber watch the Rohhammers Privileges for Web Apps. Dankeschön. Dankeschön sehr. Wir haben noch fünf Minuten frei für die ersten zwei Fragen kommen über das Internet. Hi, Daniel. Wir wollen... Wie ist das mit ECC-RAM? Wie ist ECC-RAM angreifbar? Sehr gute Frage. Danke, dass du sie fragst. ECC-RAM funktioniert ungefähr so. Du hast diese acht Chips und du hast dann noch neunten Chip der hat auch Reihen oder Rows und wenn du deine Rows hier zugreifst, dann musst du ja von dort ne Check-Summe bauen und wenn du hier zugreifst, dann musst du ja dort ne Check-Summe abfragen. Das heißt, im Endeffekt haben du auf beides Chips auf derselben Zeit und was dann passiert, ist tatsächlich unsicher. Es gibt ECC-RAM, der resistenter ist, aber es gibt auch ECC-RAM, der weniger resistenz ist gegen Rohhammer-Angriffe. Die zweite Frage ist um Internet. Franke möchte wissen, geht das andersrum auch, dass man den Servers, ob ich das so angreifen könnte, durch den Input in die Webpage? Noch mal bitte. Node.js Ah, um den Server anzugreifen. Das würde wahrscheinlich möglich funktionieren, wenn du auf dem Server JavaScript Code ausführen kannst, aber eben nur dann. Hallo? Der ECC-RAM-Question wäre meine erste gewesen. Habe ich noch eine? Die zweite ist? Ist eine kurze, eine kurz genug Refresh Rate wird das immer Rohhammer verhindern oder ist das nicht genug? Also auf meinem Laptop, den ich hier habe, da habe ich jetzt einen Bitflip gesehen, wo ich 65.000 dieses Double Hammering Operations durchführen musste, bis ich eben diesen Bitflip hatte. Das heißt, 65.000 Zugriffe in einer sehr kurzen Zeit. Ich glaube, das kann man eben nicht mit der Refresh Rate reparieren, aber die meisten Laptop und Desktop-Rechner dann wird das ausreichen. Hier ist die Antwort der Bereich, in dem du manipulieren kannst du kannst du kannst nicht in bestehenden Bars wir müssen dein Timing in dem... Du kannst nicht das so konfigurieren in allen BIOS Arten, aber wenn du es konfigurieren kannst, dann kannst du es weit genug runter setzen, dass du resistent gegen Rohhammer bist. Nächste Frage? Du hast gerade Mobile Devices erwähnt, hast du schon mal versucht? Ja, das haben wir probiert. Wir haben sogar ein Smartphone dafür in den Kühlschrank gelegt, weil das offensichtlich den Refresh-Intervall ändert. Um die Bitflips zu erreichen, musst du ja zwei Reihenangreifen behermern und jetzt gerade haben wir noch nicht reverse engineered diese Zuordnung zwischen dem Ram auf meinem Smartphone und deswegen müssen wir das noch tun. Wenn ich es richtig verstanden habe, das Hammering ist effektiver. Beim Bitkippern der schneller mann hinschlägt. Ist ASM.js Support in den Browsers macht diese Angriffe effektiver oder nicht? Meines Wissens naches ASM.js bringt dir keinen nativen Zugriff auf nativen Code. Es gibt ja nur effiziente Arten um Funktionen in JavaScript zu implementieren. Das heißt, eigentlich kannst du das auch von Hand machen. Es gibt diese Tricks wie XOR mit 0 und so was. Das ist dann ein effizienteres, optimierteres Statement auf einer CPU. Aber wir haben so mehr oder weniger was Ähnliches gemacht, um unseren Angriff in JavaScript auszuführen. Aber das ist sehr einfach, auch das ohne ASM.js zu erreichen. Du musst also nicht viele Optimierungen machen. Das ist einfach nur eine Endreferenzierung. Was kann man da schon falsch machen?