 ist das Mikro an. Hallo. Vielen Dank, dass ihr hier seid. Es freut mich so viele bekannte Gesichter zu dieser Jahreszeit zu sehen. Ich werde jetzt zum traditionellen Talk übergehen. Ich bin momentan ein Postdoc. Wir haben die letzten Jahre immer wieder Vorträge gehalten und unter anderem hat das nicht nur ich gegeben, sondern auch Rachel. Ich werde die Traditionen die Tradition aufwetterhalten und über Stilometrie sprechen. Was hat jetzt also seit dem letzten Programm ist für etwa 15 Minuten. Die Animeisierung ist einfacher geworden und das bedeutet halt oder es ist ich wie Valenzu. Es gibt mehr Besorgnisse für Programmierer, auch für Open Source Programmierer. Heute. Wir werden über Stilometrie sprechen und Maschine, Maschinele Leran. Und dazu gibt es ein Paper, das heute veröffentlicht wurde. Es ist auf, es ist auf dem Block, aber es ist auch auf archive.org verfügbar. Lasst uns anfangen mit stylistischen Fingerprints, also Fingerabdrücke, stilistische Fingerabdrücke. Stilometrie ist die Studie von Schreibarten, einige Künstler können dadurch identifiziert sein, indem man sich anschaut, wie sie schreiben. Und das gleiche gilt auch für Musiker. Durch die Töne und die Rhythmen, die sie verwenden in ihren Musikstücken, kann man diese Musiker identifizieren. Und es gibt natürlich auch unkonventionelle Texte wie Forensbeiträge in anderen Untergrundforen im Internet und dadurch kann man halt auch Leute identifizieren. Wir haben uns auch übersetzten Text, also Übersetzung von Texten betrachtet, um zu sehen, ob durch die Übersetzung ein Animisierungseffekt stattfindet oder ob man die Urheber trotzdem noch identifizieren kann. Und nun schauen wir das Quellcode an und wir schauen uns halt die Sprache und den Stil an, den die Leute verwendet haben. Und heute werde ich die Fortschritte von unserer Arbeit vorstellen. Und am Ende des Vortrags werdet ihr sehen, dass der Stil in Code kann quantifiziert und charakterisiert werden. Also was passiert bei überwachter Stülometrie? Wir können Stile identifizieren, in einigen persönlichen Schriftstücken identifizieren, mithilfe von maschinellem Lernen. Lass uns davon ausgehen, dass wir eine Menge von Dokumenten haben mit unbekannten Autoren und ihr wollt wissen, wer die Autoren waren von diesen Dokumenten. Und ihr könnt Maschinen-Learning benutzen und trainiert diese Maschinen-Learning-Algorithmen mit Dokumenten, von denen ihr wisst, wer die Autoren sind. Und danach könnt ihr dann die Maschinen-Learning-Modelle, die trainiert wurden, auf die Texte losgelassen werden, von denen die Autoren noch nicht bekannt sind. Und jetzt haben wir zum Beispiel folgendes Szenario. Alice schreibt in ihrem Blog etwas über ihren Arbeitgeber, der sie ausnutzt und Anmerkung, das übersetzt ist, das war jetzt leider zu schnell. Und wir haben ein paar beängstigende Beispiele. Also hier ist ein Beispiel und der Benutzername ist The Corner und sie twitterte, dass Cisco ihr gerade einen Job angeboten hatte. Und sie müsste jetzt abwägen die gute Bezahlung gegen die tägliche Reise nach San Jose. Und das wurde gesehen von Cisco Alert und man konnte dann identifizieren, wer The Corner war. Und in diesem Moment ist natürlich dieses Jobangebot gefährdet. Was Cisco machen kann, ist, es kann sich sämtliche Bewerbungsbriefe anschauen und damit versuchen herauszufinden, wer The Corner ist. Denn ja, anhand einer kurzen Twitter-Nachricht lässt sich das eben herausfinden. In diesem Fall war das nicht mal notwendig, denn da es sich online einige Gekäschte-Information finden ließen, wurde sie identifiziert als Connor Riley und leider ist dann das Jobangebot zurückgezogen worden. Das ist also ein Beispiel, wo man so ein Verfahren hätte anwenden können. Das heißt, wenn wir also über Maschinen lernen, reden und was es bedeutet, dass es möglich macht, Leute zu de-anonymisieren, dann sind das die Gefahren dabei. Und so was sollte man immer berücksichtigen, wenn man Informationen mit anderen teilt, dass es möglich sein könnte, euch zu identifizieren. Und was ist jetzt mit dem Quelltext? Es war jetzt vor kurzem gab es diesen Tweet und da steht drin, ich habe von einem Internet bei Apple gehört, dass sie nicht zulassen, Open Source Projekten Code beizutragen und das ist illegal, oder? Und wenn man sich an den Code anschaut, den sie bei Apple haben und dann vergleicht mit irgendwelchen verdächtigen Code, dann könnte man vielleicht herausfinden, wer diesen Code geschrieben hat. Und das ist der Grund, warum wir jetzt heute darüber reden, wie man über den Code-Steal den Programmierer identifizieren und de-anonymisieren kann. Warum wollen wir den Stil von Quelltext analysieren? Als erstes wissen wir natürlich, so genau wie jede andere Sprache ist Quelltext, wird auf einer individuellen Basis gelernt und als ein Ergebnis entwickelt man einen ganz eigenen Coding-Steal und der kann benutzt werden, um dich um euch zu identifizieren und uns hat interessiert, ob es wirklich möglich ist, das heißt, ob in dem Quelltext genügend Informationen drin sind, um seine Art Fingerprint zu erstellen, um euch zu identifizieren und vielleicht erlaubt uns, dass einige Einsichten zu gewinnen in den Software-Engineering-Prozess, wie sich vielleicht der Coding-Steal über die Jahre ändert oder wie sich fortgeschrittene Vor- und Anfängerprogrammieren unterscheiden und man kann natürlich noch weitere Funktionalität implementieren, aber die größte Motivation hier war natürlich Programmierer zu identifizieren, die vielleicht versuchen, bösartigen Code der Backdoors enthält, in Open Source-Projektor einzuchecken. Und denken wir mal an dieses Szenario hier. Analyst analysiert eine Bibliothek und in dieser Bibliothek befindet sich böser Code. Bob wiederum hat eine Sammlung von Quelltexten, von denen er die Autoren kennt. Bob kann jetzt seine Collection durchsuchen und kann dann rausfinden, wer den Code von Alice geschrieben hat. Ein weiteres Szenario. Ihr seid ein College-Student und ihr bekommt eine Programmieraufgabe und Bob ist dein Professor und er will wissen, ob ihr jetzt plagiiert habt oder nicht. Das heißt also, er kann jetzt die eingereichten Code-Stücke analysieren und kann überprüfen, ob es Ähnlichkeiten gibt zwischen den Coding-Stealen und Ähnlichkeiten und vielleicht auch Abweichungen von eurem Vorregen-Coding-Steal. Diese Beispiele sind, das sind natürlich Beispiele gewesen, die jetzt etwas für die Sicherheit tun, aber es kann natürlich auch die Sicherheit gefährden. Das heißt, man muss also ein bisschen aufpassen, wenn man das benutzt. Vielleicht kennt ihr diese Person noch aus seinem Talk letzten Jahr. Er wurde identifiziert als ein Webseitenprogrammierer einer Porno-Seite und die iranische Regierung hat das also herausgefunden und er wurde zu einer Todesstrafe verurteilt, aber da er auch Einwohner eines anderen Landes gleichzeitig war, wurde diese Todesstrafe dann umgewandelt. Aber ihr könnt sehen damit, wie das in gewissen, wie ihr in Gefahr geraten könnt, wenn ihr in einem solchen Land lebt. Reden wir also ein bisschen mehr über die technische Seite und ich möchte euch mal zeigen, wie unsere Arbeit, die neue Sachen hinzufügt zu dieser Forschung. Zuerst mal, das hier ist eine Liste, wo wir unsere Arbeit vergleichen mit ähnlichen Arbeiten. Wir sehen hier einige Unterschiede. Bisher war es immer so, dass wir, was jetzt neu bei uns ist, wir benutzen auch strukturelle Features des Codes. Wir benutzen also nicht nur Funktionsnamen, Variablenamen oder die Art und Weise, wie ihr Lehrzeichen setzt. Und als Klassifikator benutzen wir einen sogenannten Random Forest. Und ich werde euch gleich erklären, warum das bei dem Resultat dann einen ziemlich großen Unterschied macht. In der Vergangenheit war die höchste Akku, die, die höchste Genauigkeit, die erreicht wurde beim Identifizieren von Programmierern ungefähr 97 Prozent. Und wir können, wir könnten mit einer Genauigkeit von 98 Prozent eine Menge von 250 Programmierern identifizieren. Das heißt, wir haben also diese Genauigkeit schlagen können und haben, das hängt ein bisschen damit zusammen, dass wir einen größeren Datenbestand hatten. Das der größte Datensatz, den wir benutzt, der in der Vergangenheit benutzt wurde, bestand aus 46 Programmierern und das kam zu einer Genauigkeit von 75 Prozent. Nach dem Talk vom letzten Jahr waren wir in der Lage, das auf 1600 Programmierer hochzustufen und bekam dann eine Genauigkeit von etwa 94 Prozent. Bei insgesamt 14.400 Source-Coach-Schnipseln hatten wir also diese Ergebnisse. Also es ist schon eine recht große, wir konnten das also gut hochskalieren. Wie tun wir das? Wir haben ein Maschinen-Learning-Setup. Wir gehen auf Google Coach Jam, das ist ein Programmierwettbewerb, der jährlich ausgetragen wird und wir haben da Datas jetzt gesammelt. Das waren hauptsächlich C++-Coach-Stücke, denn das ist sie am häufigsten benutztes Sprach in diesem Wettbewerb. Wir hatten ungefähr 100.000 User aus verschiedenen Jahren. Das war also unser Grunddatenbestand. Und was wir damit gemacht haben, wir mussten herausfinden, welche Attribute den Coats-Deal der einzelnen Leute repräsentieren. Das heißt, wir haben eine Art Vorprozessierung gemacht, dieses Quelltextes und wir bekamen einen abstrakten Sonntagsbaum des Quelltexts mit Hilfer eines Fassi-Suntagsbaumpauses und konnten damit den Coating-Stil repräsentieren. Und diese Eigenschaften haben wir jetzt, diese Eigenschaften, die individuelle Stile repräsentieren, haben wir in den sogenannten Random Forest gefüttert. Dann haben wir das klassifiziert, also der Baumstand ist insgesamt 300 Bäumen. Warum haben wir Coach Jam benutzt? Wir konnten auf Daten von 2008 bis 2014 zugreifen. Mittlerweile gibt es auch die 2015er Daten. Der aber der wichtigste Punkt war, dass jeder, der in diesem Wettbewerb teilgenommen hat, hat die Lösung für das gleiche Problem implementiert. Das heißt, dieselben algorithmische Funktionalität und das einzige oder beziehungsweise das vorherrschende Merkmal, worun man die Quelltexte unterscheiden konnte, war der Coating-Stil dieser einzelnen Programmierer. Zur gleichen Zeit mussten sie die Funktionalität implementieren in einer begrenzten Zeit. Das heißt, sie hatten nicht viel Zeit, nur noch mal zu ihrem Code zurückzugehen und ihn zu verbessern, zu verändern oder irgendwelchen Schnipsel aus Stack Overflow hineinzukupieren. Und als die Teilnehmer dann die verschiedenen Runden durchlaufen sind, wurden die Probleme schwerer. Das heißt, wir haben auch so ein gewisser Kontrolle darüber, wie die Leute etwas komplexere Funktionen implementieren. Und als ein Resultat können wir davon ableiten, welche Programmierer, fortgeschrittene Programmierer sind und welche nicht. Und C++ war also die am häufigsten Monatsesprache und deshalb haben wir uns dafür entschieden. Okay, und wie kann man jetzt den persönlichen Coding-Stil repräsentieren? Als erstes haben wir natürlich oben den Source Code, oben haben wir als Beispiel mal fünf Zeilen und davon können wir einige lexikalische Features uns anschauen. Zum Beispiel Integer, hier Integer A ist ein lexikalisches Feature, denn das hat der Programmierer so ausgewählt. Dann haben wir natürlich die Variablen und Funktionsnamen, die halt der Programmierer sich selber ausdenkt. Dann haben wir Layout-Features wie zum Beispiel die Tabulatoren, die Leerzeichen und wo man die geschweiften Klammern hinsetzt. Aber das Wichtige ist und was uns dabei geholfen hat, den Coding-Stil zu repräsentieren auf eine sehr, sehr ausdrucksvolle Weise ist, wir haben strukturelle Features benutzt. Wir können das machen, indem wir diesen Quelltext konvertieren in einen abstrakten Sündungsbaum. Und das gibt, dass damit kommen wir an die Grammatik und Struktur des Quelltextes. Und hier kann man eine ganze Reihe von Features extrahieren. Dies sind auch schwieriger zu ändern als einfach die Variablenamen wie Foo oder A, denn die sind sozusagen in den Quelltext eingebettet. Wir extrahieren also Features aus diesem Quelltext, wie zum Beispiel Knoten, Kanten, die Häufigkeit von bestimmten Elementen oder wie oft hier diese Statement-Notes vorkommen. Und daraus bauen wir unser Featureset, was dann den Stil repräsentiert. Und warum haben wir diesen Random Forest benutzt? Zunächst mal ist das naturgemäß gibt uns das Klassif, die Möglichkeit, das nach mehreren Klassen zu klassifizieren. Random Forest ist erfolgreiche darin, viele anstatt nur ein oder zwei Klassen abzubilden. Das heißt, wir haben hier keine binäre Klassifikation, sondern sind da etwas flexibler. Im Random Forest werden auch Entscheidungsbäume benutzt in dem Trainingsprozess und das vermeidet einige der Nachteile von älteren Verfahren. Wir wollten also sicherstellen, dass wir ein bestimmtes selten auftretenes Attribut nicht über repräsentieren. Es erlaubt uns auch so eine Art Crossvalidierung vorzunehmen. Das heißt, wir haben für jeden Programmierer neun Code-Stücke gehabt und wir haben acht davon das System gefüttert und haben dann das neunte Code-Stück als Probe benutzt, um zu sehen, wie gut das funktioniert. Und dann sind wir zu dem nächsten, der das weitergegangen, um zu sehen, ob die Features, die wir daraus bekommen haben, wirklich Sinn ergeben. Okay, reden wir über die Allgemeinenfälle. Hier werde ich jetzt reden über die Art und Weise, wie wir das implementieren konnten. Also der allgemeine Fall, wer ist dieser anonyme Programmierer? Wir möchten also den Programmierer deanonymisieren. Wir möchten herausfinden, wer es ist, wie zum Beispiel den Gründer von Bitcoin. Wir wissen nicht wirklich, wer das ist. Also was passiert hier? Wir haben 1.600 Programmierer und jeder von denen gibt neun Code-Stücke. Und wir machen dann eine Crossvalidierung und extrahieren aus den Code-Sambels verschiedene Features und sobald wir unseren Klassifizierer damit trainiert haben und über die 14.400 Code-Stücke getestet haben, bekommen wir eine gewisse Genauigkeit von 94 Prozent. Wenn wir also vermuten, dass jemand der Autor von Bitcoin ist, dann nehmen wir bekannte Code-Sambels von ihm, trainieren den Klassifizierer damit und danach als Testdaten nehmen wir den ursprünglichen Git-Commit von Bitcoin, den ersten ursprünglichen Commit, der in den Bitcoin-Repository gemacht wurde. Und dann versuchen wir herauszufinden, ob der Verdächtige den Code geschrieben hat oder nicht. Und viele Leute fragen uns, wer ist Hitoshi? Und naja, wir haben eine Menge von Verdächtigen, aber der Hauptverdächtige und unserer Menge hat leider keine früheren Code-Stücke hinterlassen. Das heißt, wir lassen diese Folie einfach mal so stehen, wie sie ist. Und was passiert jetzt, wenn jemand versucht, den Code zu modifizieren, sodass nicht mehr ganz klar ersichtlich ist? Also obfascation ist das normalerweise, indem man versucht, die Herkunft des Codes zu verschleiern. Vielleicht will man damit Plagiate verschleiern oder ähnliches, aber es stellt sich heraus, dass das den Auto nicht anonym macht. Es gibt einige Soap-Code-Opfascaters. Hier ist ein Beispiel, das ist ein kommerzieller Opfascater, der nennt sich Stunnix und der ist also in der Lage, den Quelltex zu verändern. Man kann also einfach online gehen, diesen Stunnix kaufen und den auf verschiedene Sprachen anwenden. Und was dieses Programm macht, wenn man sich das mal anschaut, es nimmt sich die lexikalischen Features wie zum Beispiel die Funktionsnamen, Variable-Namen, Kommentare, Leerzeichen und so weiter und verändert die. Aber es macht keinen Unterschied in der Struktur des Programms. Das heißt, wenn wir alle Leerzeichen rausnehmen und alle Namen verändern, die Zeichen umstellen und durch Hexadezimal und ASCII-Repräsentierungen ersetzen und auch das mit den Zahlen, wie man hier sieht, dann bleibt die Struktur des Programms nach wie vor unverändert. Das heißt, wir bekommen immer noch dieselbe Genauigkeit beim Deanonymisieren des Programmierers wie vorher. Also das ist das, was passiert, wenn man es mit einfachen kommerziellerhältlichen Opfascatern bearbeitet. Wir haben für unseren Beispiel 20 Autoren genommen und haben auch nach der Opfascation immer noch eine Trefferquote von 99 Prozent gehabt. Egal, ob wir es durch den Opfascater laufen hatten lassen oder nicht, denn anhand der Strukturfeatures konnten wir das noch erkennen. Was passiert jetzt, wenn wir jetzt einen etwas besseren Opfascater benutzen? Hier ist ein Beispiel, das von Tigress stammt. Mit diesem Programm kann man verschiedene Arten von Opfascation anwenden. Wir haben hier Code, der besteht aus 14 Zeilen und wenn man das durch den Opfascater schickt, dann wird das zu 800 Zeilen. Es ist komplett unleserlich und ich glaube nicht, dass, selbst wenn irgendjemand hier ein Softwareentwickler ist, ich glaube nicht, dass die Leute, die mit euch an dem Projekt arbeiten, sehr glücklich werden, wenn ihr Code wie diesen hier kommenten würdet. Aber das funktioniert besser darin, euren Code zu anonymisieren. Das heißt, wir haben also C Programmiere für dieses Experiment benutzt und wir hatten wiederum 20 Programmiere. Wir waren in der Lage, sie mit einer Genauigkeit von 96 Prozent zu deanonymisieren. Aber wenn wir mit Tigress eine Opfascation, dass der Programmstruktur vorgenommen haben, dann haben wir nur noch eine Genauigkeit von 67 Prozent bekommen. Das heißt, wir haben also quasi einen 30 Prozent Rückgang in der Genauigkeit bekommen. Aber wenn man das vergleicht mit der Zufallswert, also wenn man einfach irgendeinen beliebigen Programmierer rauspickt, dann von 20 hat man eine Chance von fünf Prozent richtigen zu bekommen. Und im Vergleich dazu ist 67 Prozent immer noch eine relativ hohe Nummer. Das heißt, ihr seid immer noch nicht komplett anonym, sobald man diesen Opfascater anwendet. Und da habt ihr auch schon im Grunde die Antwort, Opfascation ist nicht die Lösung, damit so aus kurz zu analysieren. Was passiert jetzt mit dem Coding Steel über den laufenden Jahre? Wir wollten sehen, ob Coding Steel konsistent ist. Denn wenn das der Fall ist, dann können wir den Code von jemandem, den er vor zehn Jahren geschrieben hat und könnten diesen gegen Code von diesem Jahr halten. Und wir haben also Code von 2012 genommen, 25 Autoren haben damit unseren Klassifizierer trainiert und da kamen wir auf eine Genauigkeit von 96 Prozent. Und wenn wir nur Code nehmen, der aus 2014 stammt, dann ging die Genauigkeit hoch auf 98 Prozent. Das heißt, eine 2-prozentige Änderung in der Genauigkeit haben wir damit erreicht, indem wir nur Code vom letzten Jahr genommen haben. Und dann wollten wir noch den, den dieses Verfahren etwas generalisieren. Wir wollten also sehen, ob das wirklich nutzlich ist, ein allgemeingültiger Vorgang, der sich auch auf andere Programme hier Sprachen anwenden lässt. Und da ist das auch etwas, was andere Leute benutzen können. Und für diesen Zweck haben wir nur strukturelle Features benutzt. Wir haben den abstrakten Sündungsbaum generell benutzt, der mit Python kommt und haben so einen Abstrakt-Sündungsbaum von Python-Code generiert. Und damit waren wir in der Lage, 229 Programmierer zu de-anonymisieren, allein basierend auf diesem abstrakten Sündungsbaum und den strukturellen Features mit einer Genauigkeit von 54 Prozent. Und wenn wir die sogenannte Relax-Classification benutzen, das bedeutet also, man klassifiziert die Code-Stücke. Wir sagen aber, dass zum Beispiel hier, das ist der wahrscheinlichste Autor, das ist der zweitwahrscheinlichste Autor. Und wenn man dann die ersten fünf aus jeder Liste nimmt, dann haben wir, dann gehen wir davon aus, dass es ein Treffer war, wenn wir also einen der Topf fünf erwischen. Und mit diesem Verfahren haben wir die Genauigkeit auf ungefähr 76 Prozent erhöht. Wenn wir das für 23 Programmierer waren statt 229 bekommen wir 87 Prozent und mit diesen Top-5-Relax-Classification bekommen wir über 99 Prozent. Und wenn Sie, wenn wir zum Beispiel einen riesigen Datenbestand haben und Sie, wir können auch ein bisschen manuelle Arbeit reinstecken, aber zunächst mal würden wir gerne unsere möglichen Verdächtigen auf eine überschaubare Anzahl reduzieren und dann vielleicht nur händisch auf die Top 10 schauen, dann kann man dieses Verfahren benutzen. In unseren Ergebnissen sehen wir, dass wir hier eine neue Methode gefunden haben, um Programmierer zu de-anonymisieren. Und das zeigt, dass es da ein, ein, ein Richtig, man muss also wirklich sehr stark auf seinen Anonymität aufpassen, wenn man in Open Source Projekten mitarbeitet oder einfach nur ein Programmierer ist, denn wir werden bald über Binarys reden, anstatt über Quelltext. Und für zukämpfige Arbeit, wir planen, dass uns auch source kurz anzuschauen mit mehreren Autoren und können wir dann herausfinden, und wir wollen wissen, ob wir herausfinden können, welcher Teil von welchem Programmierer beigetragen wurde. Und wir sehen auch, dass Opfer Skation halt nicht hilft. Und Stylometrie in ex ausführbaren Binary-Programmen versuchen, wir versuchen jetzt Stylometrie auf Binary-Programme anzuwenden. Und hier ist das, was passiert. Wir haben den Quellcode, das ist nicht der gesamte Quellcode, und dann kompiliert man den, und dann hat man ein Abfolg von 0 und 1. Und können wir, und ich glaube nicht, dass wir einfach nur durch drauf schauen, die animisieren können, wer das geschrieben hat. Und ich werde jetzt den zweiten Teil von diesem Talk anfangen. Was passiert, wenn, wenn der, wenn das Programm kompiliert wird und man versucht mithilfe des kompilierten Programms herauszufinden, wer die Programme geschrieben hat. Warum wollten wir sowas tun? Zunächst einmal ist das auch einfach eine Forschungsfrage. Und dieser Coding Style existiert auch im kompilierten Code. Und das Ganze ist natürlich auch eine Bedrohung für Privatsphäre und Anonymität. Und können wir das Ganze natürlich auch benutzen für die Klassifikation von Melvere. Und ein ähnliches, ähnliche Arbeit war, stelle ich hierfürst. Sie haben auch Machine Learning verwendet und haben also diese, diese Samples wieder in den Klassifier gefüttert und haben dann versucht herauszufinden, welches Sample wir welchen Programmierer zugeordnen konnten. Und wir haben dann die, die Benäherstücke disassembliert und da uns den Kontrollfluss angeschaut, das heißt also aus den Features der Assembler Instruktionen und dem Kontrollflussgrafen, diese Informationen konnten wir benutzen, um die stilistischen Features des Quelltextes zurückzurechnen und damit waren wir wieder in der Lage, die Programmierer zu de-anonymisieren. Und wir verwenden halt Random Forest statt Support Vector Machine und wir haben halt das gleiche, die gleiche Datenmenge benutzt, um halt einen guten Vergleich mit der vorherigen Arbeit, eine andere Gruppe zu haben und wir haben eine Disassembly und eine De-Kompilation gemacht und haben dann, dann die altbekannten Feature Extraction Methoden verwenden, mithilfe der de-kompilierten Programme und wir konnten halt die gleichen Methoden nochmal anwenden und konnten dadurch dann ermitteln, welches Feature gehört zu welchem Auto und dann haben wir die, die Klassifikation durchgeführt, um die Programmierer zu identifizieren. Wir haben dann die gemeinsamen ASTs, also die Gemeinsam-App-Sex-Syntext-Strees und wir haben auch, wir haben auch Knoten Unigrams betrachtet und wir haben auch den Kontroll-Flow-Graph uns angeschaut und auch die Unigrams für den Kontroll-Flow-Graph haben wir ebenfalls angefertigt. Da das De-Kompilierer-Code ist, wird er natürlich viel länger als der normale Quelltext, aber wenn wir uns jetzt mal diese 100 Programmierer anschauen und uns die Features von denen extrahiert haben aus insgesamt 900 Executables, dann haben wir ungefähr 200.000 einzelne Features damit extrahieren können und es zeigt sich aber, dass nur 426 damit von diesen Features den Coding-Steal repräsentieren. Das heißt auf diese 426 Features konzentrieren wir uns. Was passiert, wenn wir jetzt versuchen, 100 Programmierer zu identifizieren? Wir wollten sehen, wie viel Trainingsdaten wir brauchen, also wie viele Weispiele brauche ich, um einen Programmierer akkurat zu identifizieren. Mit einem einzigen Binary Weispiel und 100 Programmierern waren wir immer noch in der Lage, sie mit einer Wahrscheinlichkeit von 20, von der Genauigkeit von 20 Prozent zu identifizieren und wir kamen bis zu einer Genauigkeit von 78 Prozent Genauigkeit mit nur acht Code-Stücken und es ist also wirklich so, wenn wir mehr Binary Samples hätten, dann wären wir in der Lage gewesen, diese Genauigkeit noch zu erhöhen, aber unser Datenbestand ließ das nicht wirklich zu mit nur 100 Programmierern. Wenn wir jetzt diese Relaxed Classification benutzen, die ich erwähnt habe, dann sind wir in der Lage mit 100 Programmierern mit einem Datum mit einem Beispielsatz der Größe 10 bekommen wir bis zu 95 Prozent Genauigkeit, das heißt wenn wir also mit 100 Binary-Daten von 100 Programmieren anfangen und man hat 10 Verdächtige, dann ist man in der Lage mit 95 Prozent Wahrscheinlichkeit zu sagen, ob der Programmierer dieses Code-Stückes in diesen Top 10 enthalten ist. Wir wollten außerdem sehen, was passiert, wenn wir einen kleineren Datenbestand haben. Wenn wir also hier mit dieser Relaxed Classification arbeiten, können wir auf bis knapp unter 100 Prozent Genauigkeit kommen, indem wir uns auf die, wenn wir 20 Programmiere haben und die Top 10 herausfinden wollen. Wir wollten außerdem noch sehen, was passiert, wenn wir nur ein einziges Trainingsample benutzen für 20 Programmiere. Mit 20 Programmieren, wenn man nur ein einziges Sample hat von jedem dieser Programmierer und also insgesamt 20 Dateien, die man zum Training benutzt und dann ein weiteres Code-Stück bekommt, dann kann man das mit einer Gewissheit von 75 Prozent identifizieren. Das ist schon ein bisschen beängstigend. Das heißt, wenn man ein einziges Binary da draußen existiert, was ihr geschrieben hat, wenn ihr in einer Menge von Verdächtigen seid, die einen insgesamt 20 Personen umfasst, dann seid ihr mit einer Chance von 75 Prozent identifiziert, dass dieses Code-Stück von euch stammt. Und das wollten wir natürlich noch ein bisschen skalieren. Das heißt, wir sind von 100 Programmierern, haben wir auf 600 erhöht und in diesem Fall können wir die, geht die Genauigkeit natürlich etwas runter. Bei 600 Programmierern bekommen wir immer noch eine Genauigkeit von etwa 52 Prozent. Es lohnt sich noch zu erwähnen, dass zum Beispiel in dem vorherigen Teil hatten wir 1600 Programmierer, aber da wir jetzt hier ein anderes Data-Set benutzen, wir haben also den Quellcode compiled, sodass wir als in einem kontrollierten, in einer kontrollierten Umgebung benutzen konnten, mit dem selben Compile-Optionen waren wir nicht in der Lage, 1600 verschiedene Binarys zu erreichen. Also verschiedene Quelltexte ergaben einfach nach dem Compile das gleiche Binary. Und die mussten wir natürlich rausnehmen. Ich mach mal. Also es gab noch nicht so viel Arbeit in diesem Gebiet, die gemacht wurden. Es gab ein Paper von Rosenblum et all, die sich damit beschäftigt haben, aber ansonsten gab es halt nicht so viel. Mit 20 Programmierern haben sie halt 77 Prozent Genauigkeit. Aber die Größe der, oder die Anzahl der Training-Samples ist nur 8 bis 16, was jetzt halt nicht so viel ist. Mit unseren, mit 100 Programmierern haben wir halt 78 Prozent Genauigkeit. Zum Beispiel wenn wir auf das 100 Programmierer-Daten-Set anschauen, dann sehen wir, dass sie halt nur 61 Prozent Genauigkeit kriegen. Und am Ende haben wir unseren Ansatz auf 600 Programmierer hochskaliert. Und das Datenset von Rosenblum et all mit ungefähr 200 Programmierern hat nur 51 Prozent geschafft, während wir 52 Prozent geschafft haben. Was passiert, wenn man Code optimiert, ist das analog zu einer Trans-Übersetzung von einem natürlichen Text in einer anderen Sprache. Und das erste Mal in der wissenschaftlichen Veröffentlichung haben wir uns dieser Frage angenommen. Und wenn es keine Optimierung gibt, haben wir 78 Prozent. Mit stripten Symbolen haben wir 65 Prozent. Und sobald wir halt mehr und mehr Optimierung angewendet haben. Und diese Optimierung sind kumulativ. Also die vorherigen Optimierung werden immer inkludiert. Das macht das ganze, das macht die Programme natürlich schneller und kleiner. Und man sieht halt, dass die Genauigkeit nicht sehr stark abnimmt. Also bei Optimierungsstufe 3 kriegen wir immerhin noch 60 Prozent Genauigkeit. Kommando, also Kompileroptimierungs sind halt keine Lösung, um den eigenen Quell, um das eigene Programm zu anonymisieren. Und wir wollten uns auch anschauen, oder wir haben uns auch angeschaut, welche Features halt das Kompilieren und De-Kompilieren überstanden haben. Und wir haben hier mit Machine Learning gearbeitet, um wo wir das gleiche Code, die gleiche Code Menge hatten und nummerische Darstellung für den Original Code und den Kompilierten Code hatten. Und wir haben dann den De-Kompilierten Code und dann haben wir geschaut, konnten wir halt, dann können wir den, können wir damit den Code, der noch nicht kompiliert wurde, rekonstruieren. Und wir haben dann die Vorhersage für die neuen Features in dem Kompilierten Code generiert. Wir haben uns die Cosinos Distance, Cosinos Ähnlichkeit angeschaut und wir haben, also wir haben den Original Code genommen und wir haben die De-Kompilierten Code genommen und wir haben uns die Features angeschaut und und und die Cosin und es waren halt 53 Prozent Ähnlichkeit, so dass man halt sieht, dass es jetzt nicht so unterschiedlich ist. Und was uns das zeigt ist, dass der Kompiland natürlich die Features transformiert, aber in den Binary Stints sind sie immer noch da. Das heißt, man kann sie ja auch in diesen Binary Detailen wiederfinden. Und das kann schon eine Sorge sein, wenn man versuchen will, anonym zu bleiben. Wir wollten außerdem sehen, ob wir irgendwelche Einsichten gewinnen können und schauen dazu, ob die Unterschiede in den Binary von Fortgeschrittenen programmieren, die bis in die schwierigen Runden des Code-Wertbewerbs vordrängen konnten. Und wenn man sich diese Binary anschaut, kann man erkennen, ob ein Programmierer erfahrener ist als ein anderer Programmierer. Was wir getan haben, ist, in dem Datenbestand haben wir, wir haben in den zwei Untermengen eingeteilt. Die eine Untermenge waren die Code-Stücke von den Leuten, die nur in den ersten sieben Runden das Problem lösen konnten. Und das zweite Menge war die Leute, die alle sieben Probleme der ersten Runde plus sieben weitere Runden lösen konnten. Und wir haben diese Beispiele benutzt, um zu sehen, ob wir das de-anonymisieren konnten. Und für die Fortgeschrittenen Programmierer hatten wir eine Genauigkeit von 88 Prozent erreicht, wenn wir ihre Binär-Dateien genommen haben, um sie zu identifizieren. Für die weniger begabten Programmierer kamen wir noch auf eine Genauigkeit von 80 Prozent. Das heißt also, es ist mehr Informationen über den Coding-Steal im Sourcecode vorhanden, je fortgeschrittener der Programmierer ist und selbst nach dem Kompilen ist das noch besser in das Binary-File transponiert. Und wir haben das selber auch probiert mit einer Untermenge aus sechs Programmieren, die nur sechs Probleme lösen könnten und eine Menge von Programmierern, die zwölf Probleme lösen konnten, also die ersten sechs plus sechs weitere und die Resultate sind analog. Die Genauigkeit ist geringer, weil die Anzahl unserer Beispiele weniger ist. Das heißt, das Maschinen-Lernen kann nicht so gut sein, aber wir bekommen immer noch eine Genauigkeit von etwa 87 Prozent und 78 Prozent bei den weniger begabten Programmierern. Wir haben also an Google Code Jam gearbeitet, das ist eine sehr kontrollierte Umgebung, um so ein Indexperiment durchzuführen aus den Gründen, die ich vorher schon erwähnt habe. Aber die Frage, die natürlich viele Leute stellen, ist, ist diese De-Anonymisierung etwas, was so erfolgreich ist, weil ihr nur Datasets aus Google Code Jam benutzt hat und wir wollten sehen, was passiert, ob es einen Unterschied macht, wenn wir De- Anonymisierung mit Code-Stöcken aus der freien Wildbahn benutzen. Und wir haben dann also Code von GitHub genommen und wir haben verschiedene Repositories gefunden, die mindestens 500 Code-Zeilen hatten und wir hatten außerdem als Kriterium, sie mussten mindestens zehn Sterne haben und die Leute sollten mehr als ein Repository auf GitHub haben. Also wir hatten schon einige Einschränkungen und wir kamen dann auf insgesamt 49 Programmierer nach dem Anwenden all unserer Einschränkungen. Wir hatten insgesamt 117 verschiedene Repositories, aber leider ist GitHub Code manchmal ein bisschen schwierig zum Kompilen. Das heißt, also nach dem Kompilen des Codes hatten wir dann insgesamt nur 12 Autoren und 50 Binarys. Auf dieser Datenmenge waren wir in der Lage, die Programmiere mit einer Genauigkeit von 62 Prozent zu De-Anonymisieren und wir haben das Gleiche dann nochmal gemacht mit Google Code Jam und genau die gleichen Zahlen benutzt, also 12 Autoren, 50 Dateien und da kamen wir auf 68 Prozent Genauigkeit. Das heißt, man sieht, dass das also ein sehr vielversprechendes Ergebnis ist, bei dem Bemühen Programmierer zu De-Anonymisieren. Und für zukünftige Arbeiten, wir wären gerne in der Lage, ausführbare Binary Dateien zu Anonymisieren, denn im Grunde, wir haben hier einen Privatsphärenproblem. Wir sind in der Lage, die Programmierer zu identifizieren mit einer sehr hohen Genauigkeit und das mit einem sehr einfachen Maschinen-Lernprogramm und wir können das auch hochskalieren. Für ausführbare Binary Dateien konnten wir zeigen, dass die Optimisierung des Compilers nicht die Lösung sind für dieses Problem und wir wären außerdem gerne in der Lage, die Autoren von Malware Binarys zu identifizieren und wir wären wirklich gerne in der Lage rauszufinden, ob wir die Malware so in verschiedene Familien einteilen könnten. Um dieses Problem zu lösen, brauchen wir eine große, eine große Bestandsdatenmenge. Also, wenn hier jemand daran interessiert ist und vielleicht da einige Daten hat, mit denen wir arbeiten können, bitte am Ende des Talks, komm zu mir und redet mit mir, vielleicht können wir da was machen. Wir haben einige Tools für euch bereitgestellt. Ihr könnt die alle online finden, ihr könnt uns auch eine E-Mail schicken, wenn ihr das mal unter verschiedenen Umgebungen probieren wollt. In unseren vorherigen Talks haben wir da auch schon nichts von gesehen. Also, fangen wir mit dem Hauptprogramm an. Zum Deanalysieren von Programmieren mittels Source Code könnt ihr einfach dann auch googeln, ihr findet dann unser Github Repository und das könnt ihr laufen lassen. Wir haben außerdem noch ein Framework, um die Autorenschaft zuzuweisen. Man kann also autorenbekannte Dokumente einfüttern eines bestimmten Autoren und dann ist man in der Lage, Dokumente zu identifizieren, von denen man nicht den Autor weiß und man hat da verschiedene Optionen, das zu machen, verschiedene Art und Weisen, die Features zu generieren. Also, man kann damit auch Erfahrung sammeln, dieses Machine Learning zu betreiben und zu sehen, wie diese Deanalysierung funktioniert und basierend auf Jay Styler haben wir Anonymous gebaut. Also Jay Styler ist ein Framework und Anonymous ist also eine Engine, die dabei hilft, deinen Schreibstil zu anonymisieren. Also, wenn ihr euch in einer Menge von Verdächtigen wiederfindet und ihr wollt sicherstellen, dass ihr darin anonym bleibt, dann könnt ihr Anonymous benutzen, um sicherzustellen, dass dieses Tool die Attribute von weiteren Verdächtigen in derselben Menge feststellt und dann euch Möglichkeiten gibt, eure eigenen Code-Stil anonymer zu machen. Das kann ein sehr hilfreiches Werkzeug sein, wenn für zum Beispiel Leute in einem Unterdrückungsregime, wenn diese also anonym schreiben wollten, um nicht in Schwierigkeiten zu bekommen, dann können sie solch ein Tool verwenden. Dann sagen wir nur zum Beispiel, ihr seid Alice mit ihrem bösartigen Arbeitgeber Bob, wenn ihr mit Tor arbeitet und deshalb denkt ihr seid anonym, dann könnt ihr trotzdem noch an eurem Stil identifiziert werden. Ich möchte an dieser Stelle all meinen Mitarbeitern danken für diese großartige Arbeit. Ohne sie wäre es nicht möglich gewesen und wenn ihr möchtet, ich habe auch noch einige weitere Folien, aber vielleicht habt ihr ja eine Reihe Fragen und dann könnten wir jetzt einfach mal mit dem Q&A anfangen und danke, dass ihr alle hier wart. Ich mache die Fragen. Wir haben ungefähr 20 Minuten für Frage und Antworten. Die erste Frage geht an das Internet, sobald die der Raum sich ein bisschen bereucht hat. Funktioniert die Technik auch an mit Shell-Kommandos, um herauszufinden, wer was mit meinem System gemacht hat. Kannst du ein bisschen lauter sprechen? Ich bin nicht sicher, ob ich die Frage richtig verstehe. Fragst du nach... Also, ja, also wenn man nur einzelne Shell-Befehle hat, ja, solange man das richtige Feature-Set dafür findet, denke ich, dass es möglich ist, aber das ist momentan nicht Teil unserer Forschung. Da wir aber in der Lage sind, das auf verschiedenste Arten von Textdateien anzuwenden, also nicht nur die Sachen, die ich in diesem Talk vorgeführt habe, bin ich der Meinung, dass wir in der Lage sein sollten, das zu tun. Schaust du dir auch Kommentare an und Style of Writing, also Schreibstil der Kommentare an? In diesen Datenbeständen wollten wir sicherstellen, dass wir niemanden eindeutig identifizieren konnten, denn das würde die Klassifikation nur verwirren. Das heißt, wir haben die Kommentare entfernt. Diese Beispiele waren alle ohne Kommentare. Wir haben es uns aber auch mit Kommentaren angeschaut und das erhöht nur noch die Genauigkeit. Was denkst du über ... Wäre es denkbar, ein Compiler-Switch zu haben, um halt den Compiler den ganzen Kram anonymisieren zu lassen? Das ist ein sehr guter Punkt und ist auch ähnlich wie AnonyMouth arbeitet, denn man versucht da, diese Menge an Features zu modifizieren, durch die du identifiziert werden kannst. Das ist ein gutes Experiment, was man vielleicht in der Zukunft mal versuchen kann. Ich werde das mal im Hinterkopf behalten, wenn wir da weitere Arbeit verrichten. Lass uns sagen, ich schreibe Code für ... Ich bin Iraner und schreibe Code für eine Pornowebseite. Und ich möchte das natürlich komplett anonym machen. Also aber das ist natürlich nicht möglich, das komplett anonym zu machen. Kann ich meine Chancen maximieren, um nicht identifiziert zu werden und dann exekutiert zu werden? Zunächst mal mit diesem Beispiel, wo da jemand identifiziert wurde. Das war nur, weil sein Name im Code drin stand. Das konnte man also direkt tun. Aber wie du schon gesagt hast, wenn du sehr vorsichtig bist und willst nicht identifiziert werden, dann kannst du vielleicht sehr strikten Konventionen folgen und du kannst sich erstellen, dass jeder andere in dem Projekt den gleichen Konventionen folgt, so dass der Code von euch allen sehr, sehr ähnlich aussieht und es nicht möglich ist, einen Einzelnen von euch zu identifizieren. Das ist also eine mögliche Lösung oder zumindest könnte es helfen. Ich vermute all diese Zahlen, die du hast, da hattest du eine Menge von Leuten und du wusstest auch, dass es eine Person gab, die halt sozusagen die Testperson war, um das zu reproduzieren. Hast du auch schon mal versucht, das komplett unabhängig zu machen, um zu überprüfen, dass eine bestimmte Person halt nicht Teil eines Sets von Verdächtigen ist? Das ist sowas, was ich hier auf dieser Slide habe. Das ist so eine Art Identifizierungsproblem beim Maschinenleeren. Es ist also so eine Klassifikation, die dir dabei helfen kann, zu verifizieren, dass ein anonymes Code Stück von jemanden kommt, der in der Menge der Verdächtigen ist oder nicht, oder mit denen ihr den Klassifiziere trainiert hat. Und was wir gemacht haben ist, wir haben Mallory und Mallory behauptet, dass dieses Stück Code von ihr stammt und wir wollen herausfinden, ob sie es wirklich geschrieben hat. Das heißt, wir haben also zwei Klassen, dass die eine Klasse nur Code Weispiele von Mallory und die zweite Klasse enthält Code Weispiele von x-beliebigen Leuten. Das heißt, das repräsentiert die Welt da draußen, jede andere außer Mallory. In diesem Fall können wir den Code von der Mallory behauptet, dass sie ihn geschrieben hat und können sehen, ob es sie wirklich geschrieben hat oder nicht, oder ob es stattdessen von dem Klassifizierer der Außenwelt zugeordnet wird. Und für diesen Fall bekommen wir eine Genauigkeit von 91 Prozent, wenn wir das 80-mal durchführen. Und wenn ihr darüber mehr Informationen willst über die Fresh-Holes, die wir benutzt haben und ähnliches, schau dir das erste Paper an, was wir da gezeigt haben. Oder wir können auch nachher noch mal drüber sprechen. Und wenn ihr nicht weiß, oder wenn man nicht weiß, wer es sein könnte, wie würde man dann vorgeben, um sicherzustellen, dass es halt nicht irgendwelche Leute aus einem Set von 50 Leuten ist? Denken wir mal an die Stelle von diesen zwei Klassen an 50 Klassen, also 50 Programmierer, wenn ein Code-Sample einem einzelnen Programmierer zugeordnet wird und die Wahrscheinlichkeit dafür einen gewissen Schwellwert unterschreitet, dann kann man sagen, es sieht noch so ein bisschen aus nach dieser Person, aber es ist eben nicht mehr sicher. Also man ist dann mit dieser Einordnung nicht übermäßig genau. Wie sieht es mit Coding Style geil aus, weil viele Sprachen Guidelines oder Richtlinien haben und die dann auch den Code automatisch umwandeln können? Ja, die eine Frage vorhin war ähnlich. Also wenn ihr euren Code-Steal normalisieren könnt in einem Projekt mit mehreren Leuten, dann ist das auf jeden Fall herrlich. Das Problem mit diesem Experimental-Setting-Problem ist, dass man sich auch als Normalisierung vorstellt, dass man sich auch als Kompilen normalisieren kann. Es konvertiert alles nach einer bestimmten Menge von Regeln und das Endergebnis ist dann sehr ähnlich. Aber selbst in diesem Fall waren wir noch in der Lage, die Programmierer zu de-anonymisieren, wenn auch mit niedriger Gerenauigkeit. Also es kann dir dabei helfen, die Wahrscheinlichkeit zu verringern, aber eine endgültige Lösung ist es sicherlich nicht. Das Problem bei diesen experimentellen Code-Basen war immer, wir hätten gerne Code-Samples gehabt von Programmierern, die allen in gleichen Konventionen folgen, um da bessere Antworten zu dieser Frage zu bekommen. Kennt ihr, kann man die Technik auch benutzen, um ein Code so zu fälschen, dass es so aussieht, als wenn davon jemand anderen geschrieben wurde? Ja, das ist möglich mit Maschinen-Learning, denn zum Beispiel mit diesem Anonymouth, wo man seinen Schreibstil, nicht Codingstil, sondern Schreibstil anonymisieren kann, was wir tun ist, man versucht sozusagen in der Menge unterzugehen, man versucht Features hineinzubringen, die nicht den eigenen Stil repräsentieren, aber wenn man Features reinbringt, die jemandem anderen gehören und man kann sehen, was diese Features sind, dann ist dein Stil anschließend ähnlicher zu dem Stil dieser einen Person. Wenn man eine neue Art und Weise, die man in der Zeit nicht mehr hat, für Qualtex, dann sollte das auch möglich sein. Du hast gesagt, es gibt ein Unterschied zwischen Einfachen und Fortgeschrittenen programmieren. Wenn man jetzt eine Reihe von Binaire-Programmen hat, kann man entscheiden, wer jetzt fortgeschritten und wer nicht fortgeschritten ist? Das ist eine gute Frage, wir haben es nicht ausprobiert, aber man kann wahrscheinlich mit Multi-Endgrams machen, aber es dauert sehr lange, diese Features zu extrahieren und dann in einen Klassifizierer umzuwandeln. Was wir gesehen haben, ist, sobald man mehr Endgrams hat oder eine große Art und Weise, dann kann man die Features extrahieren und dann in einen Klassifizierer umzuwandeln. Was wir gesehen haben, ist, sobald man mehr Endgrams hat oder eine große Art und Weise oder eine große Variabilität von Features ändert das nicht wirklich die Genauigkeit, denn die ist bereits schon so groß und was wir außerdem vermeiden wollten, war zu sehr ins Detail zu gehen, die dann den Klassifizierer vielleicht ungenauer werden lassen. Gleichzeitig wollen wir aber auch einen Zuschuss haben, der es uns erlaubt, unseren Analyseerer zum Beispiel unter Amazon zu laufen zu lassen, das wäre dann sehr viel schneller, aber ich würde trotzdem nicht Tausende oder Millionen von Features extrahieren wollen. Was die zweite Frage angeht, ja, wir können das auch unbeaufsichtigt machen, wir können das machen basierend auf verschiedenen Eigenschaften, die man in Code findet und diese Eigenschaften, eine von diesen Eigenschaften könnte der Code Steel sein, es ist möglich, aber soweit, wir haben es noch nicht ausprobiert. Hast du darüber nachgedacht, mit Metadaten über Code zu klassifizieren, also Git-Commits oder Git-Commit-Messages oder die Verwendung von bestimmten Libraries verwendet, um halt Programmierer zu identifizieren? Am Anfang, als ich das Projekt angefangen habe, habe ich genau das benutzt, was du eben schrieben hast, mit Git-Kommentaren und alles. Ja, das ist möglich, man kann auch auf diese Art und Weise Programmierer identifizieren und es macht das wahrscheinlich nur noch mächtiger. Mit Git-Hub wird das aber zu einem ganz größeren Problem, also wir kommen dann an eine Stelle, wo wir dann Quelltecks angucken müssten, der von verschiedenen Autoren stammt und wir arbeiten da dran, aber auch schon. Mit eurer Methode ist es auch möglich, die Modelle zu extrahieren, so dass man die Modelle so stark trainieren kann, dass man sie von einer Programmiersprache auf eine andere übertragen kann, so dass man quasi ein Modell nur mit einer Sprache trainiert, aber dann auf eine andere loslässt. Das ist eine sehr gute Frage, wir haben das noch nicht ausprobiert. Es ist ein bisschen schwierig dazu so Grunddaten, so finden selbst bei dem Google Code Jam, manche Programmierer schreiben in verschiedenen Sprachen, aber das ist eine sehr kleine Menge, also wir haben es uns noch nicht so genau angeschaut, aber wenn wir C und C++ zum Beispiel uns anschauen, dann kann man wahrscheinlich die Ergebnisse des einen auf die andere anwenden, weil diese Sprachen sehr ähnlich sind. Next question goes to the internet. Would that also work on assembly because you do not really have something like that. Would assembler funktionieren, also assembly language? Mit assembler Sprache ist es so, da gehe ich noch mal zurück auf diese Folie hier, hoppla. Jetzt habe ich es zugemacht, einen Moment bitte. Wir haben einige wichtige Features, die von assembler her kommen, und es ist sehr schwer zu verstehen, was diese Features bedeuten. Okay, hier haben wir es. Mit assembler Feature haben wir hier, wir haben zwei verschiedene disassembler benutzt, und wir haben nicht sehr viele Features rausziehen können, aber wir haben insgesamt etwas über 100, und es ist sehr schwierig genau zu sagen, was diese bedeuten, denn manche von diesen Unigrams sehen aus, als ob sie vielleicht zu genau sind oder zu spezifisch, aber wir haben einige Experimente gemacht, die man assemblierend beibehalten kann. Beantwortet das halbwegs deine Frage? Okay, das war eine Onlinefrage, wir können es nicht sagen. Denkst du, es ist auch möglich, diese Forschungsergebnisse auch mit Social Graph Ergebnissen kombinieren? Ja, man kann das machen. Das ist einfach nur ein weiteres Machine Learning Feature. Das heißt, man kann den Klassifizierer verbessern. In diesem speziellen Stückforschung haben wir uns einfach nur auf den Coding Style konzentriert und wollten den Klassifizieren. Wir wollten die Informationen, die für uns in dem Moment nicht relevant waren, ausklammern, aber grundsätzlich ja. Hast du auch Versuch, die verschiedenen Compilers angeschaut, der gleichen Sprache, weil GCC oder LLVM verschiedene Binerkode produzieren, macht das eine Rolle, spielt das eine Rolle? Ja, es hilft vielleicht ein bisschen, da verschiedene Compiler durchzuprobieren. Wir haben diese Frage uns nicht im Detail angeschaut, denn wir sehen, dass die Erkennung von Compilern ist eigentlich ein ganz eigenes Problem. Das heißt, also solange wir den Compiler kennen, dann können wir mit einem Satz von Parameter einen Satz von Parameter herausfinden, um diese Features des Compilers wieder rauszurechnen. Aber sobald man also anfängt, verschiedene Compiler zu mischen, dann kann dir das durchaus dabei helfen, deine Anonymisierung ein bisschen zu verstärken. Ja, danke. Was ist die Wahrscheinlichkeit, dass das nicht einfach nur Glück ist, den eine Person zu identifizieren? Wenn man jetzt, ich glaube, 75 Prozent für zwölf Programmierer hat, ist das nicht eher zufällig? Ja, es ist ein bisschen schwierig, über statistische Signifikanz zu reden, weil wir hier eine recht kleine Datenmenge haben. Aber wir können es zumindest vergleichen mit den Google-Coacham-Data-Sets, weil das doch eine signifikante Menge ist. Wir würden das auch gerne auf größere Datenmengen aus der echten Welt anwenden. Es ist eine sehr gute Frage, und wir denken bereits darüber nach. Eine letzte Frage. Welche Variablen waren am wichtigsten in der Random Forest Analyse? Da muss ich nochmal gerade zu dieser Folie zurückgehen. Die wichtigsten waren, meinst du, echte Variablen? Oder reden wir hier von Features? Für das Zuordnen von Quelltext zu Autoren, das wichtigste Feature in diesem Random Forest sind diese Word-Unigrams. Das sind also Funktionsnamen oder die Wahlformennamen für Integers oder Doubles. Denn das sind so Sachen, die direkt aus deinem Quelltext kommen. Und wir haben diese Bygrams, die aus dem abstrakten Sonntagsbaum kommen, und wir haben diese bygrams, die aus dem abstrakten Sonntagsbaum kommen. Obwohl die eine geringere Prozentzahl haben, ist die Anzahl der Informationen, die wir daraus gewinnen, ungefähr equivalent zu der Gesamtmenge der Informationen. Das heißt also, die AST-Bygrams sind die wichtigsten davon. Ja, die Zeit ist um. Und damit verabschieden auch wir uns, wir...