TextStegoSynthesis – Digitale Selbstverteidigung

Von UrsInformatik, Sicherheit

TextStegoSynthesis – Digitale Selbstverteidigung

ZusammenfassungIm Rahmen des Moduls “Digitale Selbstverteidung und IT-Sicherheit” der Otto von Guericke Universität ist darzustellen, wie verschiedene Steoganografieverfahren die Geheimnachrichten (Hiddenmessage) verstecken und wie diese durch dritte Personen erkannt werden könnten. (vgl. )

Einleitung

[UB] In der Einleitung wird die Aufgabenstellung dargestellt und auf die Motivation der Arbeit eingegangen. Darüber hinaus werden die einzelnen Kapitel kurz beschrieben.

Augabenstellung

Kapitelbeschreibung

Stand der Technik

Grundlagen

[UB] E-Mails bestehen grundsätzlich aus einen Header und einen Body. Der Header beinhaltet Informationen, die zur Bearbeitung einer E-Mail erfoderlich sind. Diese dürfen nicht verändert werden, da sonst ein SMTP-Agent die E-Mail verwerfen würde. (vgl. ) Im E-Mail Body ist die eigentliche Nachricht enthalten. Diese kann gezielt verändert bzw. manipuliert werden um Geheimenachrichten zu verstecken.

Begründung notwendiger Untersuchungen

IronGeek

Unicode Tags Stego

[UB] Dieses Stegografieverfahren fügt dem Text non-printable Zeichen (im Bereich U+E0000 bis U+E007F) den Text hinzu, um die Hiddenmessage zu verstecken.

  • countMeTags(): Diese Funktion aktualisiert die Anzeige der Anzahl der Zeichen in verschiedenen Eingabefeldern auf der Benutzeroberfläche.
  • encodeResultTags(): Hier wird der eigentliche Codierungsvorgang durchgeführt. Die Funktion nimmt den Text aus dem Eingabefeld „inputbox“ und platziert ihn in einem anderen Text, der im Eingabefeld „coverbox“ enthalten ist. Die Codierung erfolgt durch die Umwandlung der Unicode-Zeichen in spezielle Codes, die dann in den Text eingefügt werden. Das Ergebnis wird im Eingabefeld „stegoputbox“ angezeigt.
  • decodeResultTags(): Diese Funktion führt den Umkehrvorgang durch. Sie nimmt den codierten Text aus dem Eingabefeld „stegoputbox“ und extrahiert die ursprünglichen Unicode-Zeichen, die im Eingabefeld „inputbox“ angezeigt werden.
  • fixedCharCodeAt(): Eine Hilfsfunktion, die den Unicode-Wert eines Zeichens an einer bestimmten Position in einem String zurückgibt. Sie behandelt auch surrogate pairs im UTF-16-Zeichensatz.
  • RealCharCount(): Diese Funktion zählt die tatsächliche Anzahl von Zeichen in einem String und berücksichtigt dabei auch surrogate pairs.
  • utf16Encode(): Eine Funktion zum UTF-16-Encoding von Unicode-Zeichen.

More Advance Stego

[IronGeek] Dieses Stegografieverfahren fügt nicht nur non-printable Zeichen hinzu, sondern ersetzt Buchstaben mit Homoglyphen. Die Idee beruht auf Mick Douglas ().

  • charmappings: Ein Objekt, das Zuordnungen zwischen bestimmten Buchstaben und Zahlen enthält. Diese Zuordnungen werden verwendet, um Buchstaben durch eine bestimmte Anzahl von Bits zu ersetzen.
  • countMeAdvancedStego(): Diese Funktion aktualisiert die Anzeige der Anzahl der Zeichen im Decktext (coverbox) und gibt an, wie viele Bits codiert werden können. Sie zeigt auch die Anzahl der Bits an, die im Eingabefeld (inputbox) codiert werden können.
  • encodableBits(): Diese Funktion zählt die Anzahl der Bits, die im Decktext codiert werden können, basierend auf den Zuordnungen in „charmappings“.
  • encodeResultAdvancedStego():
    Hier erfolgt der Codierungsvorgang. Die Funktion ersetzt Buchstaben im Decktext durch vordefinierte Bitmuster, die auf den Zuordnungen in „charmappings“ basieren. Das Ergebnis wird im Eingabefeld „stegoputbox“ angezeigt.
  • decodeResultAdvancedStego(): Diese Funktion decodiert den Text im Eingabefeld „stegoputbox“ und stellt den originalen Text im Eingabefeld „inputbox“ wieder her.
  • GetBin(): Diese Funktion konvertiert den Text in Binärdarstellung, wobei jedem Buchstaben ein festes Bitmuster zugeordnet ist.

Butt Ugly Latin Wide Version

[IronGeek] This one is a bit crappy and causes a ’ransom letter’ type of look. It encodes bits by alternating between normal and full width Latin. It uses 7 bit ASCII to save space.

  • countMeLatinWide(): Diese Funktion aktualisiert die Anzeige der Anzahl der Zeichen im Decktext (coverbox) und gibt an, wie viele Bits codiert werden können. Sie zeigt auch die Anzahl der Bits an, die im Eingabefeld (inputbox) codiert werden können.
  • encodeResultLatinWide(): Hier erfolgt der
    Codierungsvorgang. Die Funktion prüft, ob genügend Decktext vorhanden ist, um den Binärstring aus dem Eingabefeld „inputbox“ zu codieren. Wenn ausreichend Decktext vorhanden ist, ersetzt sie bestimmte lateinische Buchstaben durch ihre Varianten mit erweiterter Breite oder fügt Leerzeichen mit breiter Breite ein. Das Ergebnis wird im Eingabefeld „stegoputbox“ angezeigt.
  • decodeResultLatinWide(): Diese Funktion decodiert den Text im Eingabefeld „stegoputbox“ und stellt den ursprünglichen Text im Eingabefeld „inputbox“ wieder her. Sie prüft, ob ein Zeichen im erweiterten Bereich (über ASCII 255) liegt, und verwendet dies als Indikator für ein codiertes Bit „1“.
  • GetBin(): Diese Funktion konvertiert den Text in Binärdarstellung, wobei jedem Buchstaben ein Bitmuster zugeordnet ist.

Steg.git

[UB] Dieses von Deeze  entwickeltes Steganographie ersetzt Whitespaces im Text und fügt, falls nötig, weitere Leerzeichen hinzu.

  • Steganographie-Kodierung (Modul ‘encode‘): Das Modul ‘encode‘ nimmt eine Nachricht und eine Decke, indem es die Nachricht in der Decke kodiert. Es verwendet einen Bitstream, um die Nachricht und die Decke als Folgen von Bits darzustellen. Die Konstante ‘EQUIV_DCHAR‘ definiert eine Menge äquivalenter Zeichen in UTF-8, die alle als Leerzeichen für
    Kodierungszwecke behandelt werden. Die Struktur ‘Bitstream‘ repräsentiert einen Strom von Bits und wird für die Kodierung und Dekodierung verwendet.
  • Steganographie-Dekodierung (Modul ‘decode‘): Das Modul ‘decode‘ extrahiert eine verdeckte Nachricht aus einer gegebenen Eingabe (verdeckte Datei), indem es bestimmte Zeichen als Leerzeichen interpretiert und die entsprechenden Bits dekodiert.
  • Bitstream-Implementierung (Modul ‘bitstream‘):
  • Die Struktur ‘Bitstream‘ repräsentiert einen Bitstream, der durch Chunks zugegriffen wird. Sie bietet Methoden zum Konvertieren von Zeichenketten in Bitstreams, zum Konstruieren von Bitstreams aus Bitarrays, zum Überprüfen, ob der Stream leer ist, zum Zugriff auf den Anfang des Streams und zum Popen des Anfangs des Streams.

SNOW

Minimale und maximale Anforderungen genutzte Parameter

[FB,UB,NF]

Konzept

Grundlegende Idee

Entscheidung für den E-Mail-Body

[UB] Der E-Mail-Header wird nicht dazu genutzt, um vertraulicher Informationen zu verstecken – er wird abgeschnitten. Stattdessen liegt der Fokus auf dem E-Mail-Body, der als geeigneter Bereich für die Synthese von Stegotexten dient. Dieser Schritt ist entscheidend, weil der E-Mail-Header für die Verarbeitung durch den SMTP-Agenten erforderlich ist.

Metrik

…

Implementierung und Versuchsaufbau

Projektstruktur

…

Versuchsaufbau IronGeek

[UB] Die IronGeek-Website ist öffentlich zugänglich und erfordert lediglich ein internetfähiges Gerät mit einem Browser, der JavaScript unterstützt. (Es ist notwendig, NoScript entsprechend anzupassen, um die Webseite nutzen zu können.)

Für die Strukturierung der Daten wird ein automatisierter Browser verwendet, der mithilfe von Selenium () gesteuert wird. Die Programmierung erfolgt in Python (). Um auf Elemente der Webseite zugreifen zu können, ist der Einsatz von XPATH (Adresse von Elementen auf der Webseite) erforderlich. Dies ermöglicht das Kopieren des Textes und das Speichern des Stegotextes.

Der gesamte Prozess zur Verarbeitung einer Hiddenmessage dauerte etwa 12 Stunden.

Versuchsaufbau Steg.git

[UB] Das Softwareprogramm steht frei zugänglich auf GitHub () zur Verfügung. Der Programmcode wird heruntergeladen und durch die Anwendung des make-Kommandos kompiliert.

Im Rahmen der Textstegosynthese wird ein Bash-Skript genutzt, welches sämtliche Textdateien durchläuft, die versteckte Nachricht einfügt und das Ergebnis in einem separaten Ordner ablegt. Der Befehl für diesen Vorgang lautet: „steg -c datei -o datei-Stegotext1.txt -i Hiddentext.tt“. Die Ausführung des gesamten Prozesses beanspruchte etwa eine Minute.

Unsere Versteckten Nachrichten

[UB] Im Rahmen dieses Projektes werden folgende Nachrichten versteckt:

  • „Tonight’s code reveals the hidden truth.“
  • „Beneath blooming petals, secrets whisper in the wind.“
  • „Amidst crashing waves, encrypted whispers dance in the sea’s rhythm. Secrets linger in the salty breeze, weaving tales of hidden truths“

Evaluierung – Versuchsdurchführung – Diskussion der Ergebnisse

Kurze Einblick auf unsere Erwartung

[UB] Die beigefügte Darstellung (weitere Details im Anhang) veranschaulicht die übliche Verteilung von Buchstaben in E-Mails und Dokumenten. Innerhalb dieser Analyse sind zwei Symbole besonders hervorzuheben: das Leerzeichen
(“ „) und der Buchstabe „e“. Die Erkenntnisse basieren darauf, dass das Leerzeichen die Wörter voneinander trennt und der Buchstabe „e“ in der englischen Sprache besonders häufig vorkommt.

Die Grafik zeigt markante Spitzen genau bei diesen beiden Zeichen. Das Leerzeichen spielt eine zentrale Rolle bei der Textstruktur, indem es Wörter voneinander abgrenzt und somit die semantische Bedeutung von Sätzen formt. Gleichzeitig wird deutlich, dass der Buchstabe „e“ signifikant häufiger auftritt als andere Buchstaben. Dieses Phänomen spiegelt die linguistische Realität der englischen Sprache wider, in der „e“ eine herausragende Rolle bei der Wort- und Satzbildung spielt.

Diese charakteristischen Ausschläge sind auch bei Steganographieverfahren zu erwarten, da sie einen Einblick in die Struktur und die häufigsten Zeichen in der Kommunikation bieten.

typische Verteilung der Buchstaben über die E-Mails

Whitespace Manipulation

Gemeinsamkeiten:

Die größte Gemeinsamkeit ist die Veränderung der Dateigröße, hierbei zeigen alle von den analysierten Verfahren erstellten Dateien eine erhebliche Größenänderung im Vergleich zu ihren Originaldateien. Bei allen Verfahren führte das Verstecken der Nachricht zu einer signifikanten Zunahme der Dateigröße.

Auszug aus den Größentabellen für SNOW für die unterschiedlichen Hiddenmessages; alle Größen in byte

E-MailOrginalHiddentextStegotextDifferenz
301425401835410
311814402217403
3219910613931194
33224510633961151
3464210618301188
35273513642041469
3669113621861495
37102613625101484

Auszug aus der Größentabelle für Stego 5 bei langen Hiddenmessage; alle Größen in Byte

PathOrginalHiddentextSteg.git StegotextDifferenz
11435401364108568
11534181363986568
11623291362945616
11754491366017568
11826861363258572
11928651363433568
1201221513612783568

Eine Weitere Gemeinsamkeit der Whitespace Manipulatoren ist die Unbemerkbarkeit gegenüber dem menschlichen Auge. Wird der Stegotext in einer üblichen Textumgebung geöffnet, so sind grammatisch und semantisch sowie bei den Verwendeten Zeichen keine Auffälligkeiten erkennbar.

In der Zeichenverteilung hingegen sind sie dafür umso auffälliger. Außer SNOW, welches zusätzliche Leerzeichen verwendete, fügten alle Verfahren dem Original neue, meist breitenlose oder unsichtbare Zeichen hinzu. Diese Zeichen sind:

  • U+200C (breitenloser Nichtverbinder)
  • U+200B (breitenlose Leerzeichen)
  • U+2060 (Wortverbinder)
  • U+00A0 (geschützes Leerzeichen)
  • U+2000 bis U+2005 (Leerzeichen mit verschiedene
    breiten)
  • U+2008 (geschützes Leerzeichen)

Während diese Zeichen mit dem Auge nicht zu erkennen sind kann man sie jedoch in der Zeichenverteilung erkennen.

Durchschnittliche Differenz-Buchstabenstatistik bei Steg.git

Unterschiede

Die Verfahren nutzten trotz einigen Gemeinsamkeiten unterschiedliche Whitespace-Techniken. Unterschiedliche Programme führen unterschiedliche Zeichen bei der Synthese ein, während SNOW komplett auf neue Zeichen verzichtet und stattdessen die Verteilung der Leerzeichen verändert.

Des Weiteren haben die Verfahren unterschiedliche Anforderungen an den zusätzlich benötigten Speicherplatz für die versteckten Nachrichten. Hierbei benötigen einige Tools mehr Speicherplatz um die gleiche Menge an Informationen zu verstecken. SNOW zeigt dabei einen erheblichen Anstieg der Dateigröße. (siehe Tabelle 1, 2)

Auch in den Anforderungen und Parametern existieren Unterschiede. Während es bei den Whitespace Programmen keine Probleme mit maximalen Anforderungen gibt, benötigen einige ein Minimum an Coverfile, um richtig zu laufen.

Auffälligkeiten

Bei allen Verfahren treten signifikante Auffälligkeiten in der Zeichenverteilung auf, welche den Text auch ohne einen Vergleich mit dem Original bereits als Steganographie enttarnen können. Darunter besonders die neu hinzugefügten Zeichen aber auch die Leerzeichenhäufigkeit.

Homoglyphen

Durchschnittliche Differenzbuchstabenstatistik bei More Advance Stego – Mittellanger Hiddenmessage

Durchschnittliche Differenzbuchstabenstatistik bei Butt Ugly Latin Wide Version – lange Hiddenmessage

Auszug aus der Größentabelle für Butt Ugly Latin Wide Version bei langer Hiddenmessage; alle Größen in byte

E-MailOrginalHiddentextStegotextDifferenz
11435401364528988
11534181364406988
11623291363317988
11754491366437988
11826861363674988
11928651363853988
1201221513613203988
12169811367969988

[UB] Der Algorithmus Butt Ugly Latin Wide Version ersetzt die Buchstaben durch ähnliche Buchstaben der „Latin Wide Version“. Dies führt dazu, dass der erzeugte Text für Menschen schwer lesbar ist, da die Buchstaben durch Homoglyphen ersetzt werden. Programme wie Thunderbird () oder LibreOffice Presentation () können jedoch diese Buchstaben und Homoglyphen korrekt anzeigen. Die Größe der Hiddenmessage-Datei vergrößert sich bei diesem Verfahren um den Faktor 8 (siehe Tabelle 3). Der Algorithmus ersetzt intensiv alle Buchstaben des Alphabets, unabhängig von Groß- oder Kleinschreibung. Dieser Vorgang ist in Abbildung 4 dargestellt und die Buchstaben werden ersetzt, bis die Hiddenmessage vollständig versteckt ist. Dies führt jedoch zu einem Bruch im Lesefluss zwischen den schwer erkennbaren Homoglyphen und den normalen Textsymbolen (siehe Abbildung [fig:lesebruch_stego4] im Anhang).

Der andere Algorithmus, Mode Advance Stegano, ersetzt die originalen Buchstaben durch ähnliche Buchstaben, auch bekannt als Homoglyphen. Im Gegensatz zum Algorithmus „Butt Ugly Latin Wide Version“ kann ein Mensch diese Art von Buchstaben nicht direkt mit dem Auge erkennen. Der Text bleibt subjektiv konsistent im Lesefluss und es werden keine Auffälligkeiten im Vergleich zum Originaltext erkannt. Weder der durch die Tastatur eingegebene Text noch der erzeugte Stegotext können von einem Menschen erkannt werden. Unterschiede in den Symbolen können nur in Programmierumgebungen angezeigt werden, die darauf überprüfen. Im Test wurde festgestellt, dass VS-Codium (Programmierumgebung) direkt anzeigt, dass der Text „non-ASCII Characters“ (siehe Anhang [fig:stego3_vsc]) enthält und daher nicht für die Programmierung geeignet ist. Die Hiddenmessage-Datei vergrößert sich bei diesem Verfahren um den Faktor 4 (siehe Tabelle [tab:ir2_stego3_diff]).

Einige bemerkenswerte Merkmale In Abbildung 3 wird die Ersetzung der Buchstaben deutlich dargestellt. Einige Beispiele sind dort aufgeführt, weitere Informationen sind in 3 oder im Anhang verfügbar. Auffällig im Histogramm ist, dass die Ausschläge auch bei Leerzeichen vorhanden sind. Dies lässt sich darauf zurückführen, dass die Algorithmen auch die Whitespace-Manipulation, wie im Kapitel 5.2 beschrieben, nutzen. Die Leerzeichen (U+0020) haben eine relative, absolute Änderung von 90 Einheiten und werden durch Symbole wie:

  1. U+2004 ( )
  2. U+2005 ( )
  3. U+2006 ( )
  4. U+2008 ( )
  5. U+2009 ( )
  6. U+202F ( )

ersetzt.

Eine zweite Auffälligkeit betrifft die Vokale, die zusammen 127 Einheiten haben, vor allem bei den Kleinbuchstaben. Dies ist nicht überraschend, da Vokale in der natürlichen Sprache oft verwendet werden und unsere Sprache auf ihnen aufbaut. Die Ersetzungen für Vokale sind beispielsweise

  1. U+0391 (A) statt U+0041
  2. U+039F (O) statt U+004F
  3. U+0415 (E) statt U+0045
  4. U+0430 (a) statt U+0061
  5. U+0435 (e) statt U+0065
  6. U+0456 (i) statt U+0069.

Die dritte Auffälligkeit betrifft das „n“, das eine relative Änderung von 40 Einheiten aufweist. Weitere Homoglyphen für „n“ wurden nicht gefunden und dies ist auf den Einfluss der Whitespace-Manipulationen und der Hinzufügung weiterer Zeichen zurückzuführen. Diese Änderungen beeinflussen die relative Verteilung der Buchstaben im Text, das zu einem „False-Positive“ führen kann, die bei genauerer Untersuchung möglicherweise nicht so relevant sind. Weitere Informationen zur Whitespace-Manipulation sind im Kapitel „Whitespace Manipulation“ () beschrieben.

Gemeinsamkeiten: Beide Algorithmen zeichnen sich durch die gemeinsame Eigenschaft aus, die Hiddenmessage im Stegotext durch die Ersetzung mit lesbaren oder unlesbaren Homoglyphen zu verbergen und gleichzeitig die White-Space-Manipulation zu nutzen, wie im Kapitel beschrieben. Der Algorithmus „Mode Advance Stego“ erweitert die Whitespace-Manipulation, indem er normale Buchstaben in die Steganografie einbezieht. Dies ermöglicht potenziell mehr Informationen und resultiert in einem effizienteren Algorithmus. Beide Versionen des Algorithmus können keine Schlüssel oder Parameter akzeptieren. Im Test können nur die Coverfile und die Hiddenmessage eingegeben werden, um den Stegotext zu erzeugen, oder der Stegotext kann eingegeben werden, um die Hiddenmessage zu rekonstruieren. Die Anzahl der verwendeten Symbole im Stegotext beträgt bei beiden Verfahren 130, im Vergleich zu den 90 Symbolen des Coverfiles. Es ist zu beachten, dass Blank Files, die beispielsweise nur aus Buchstaben „A“ und Zeilenumbrüchen bestehen, ebenfalls funktionieren. Es wird davon abgeraten, Programmcode als Coverfile zu verwenden, da dieser nicht mehr kompiliert oder ausführbar ist. Die beiden Algorithmen benötigen siebenmal längere Coverfiles als Hiddenmessagefiles, um zu arbeiten.

Fazit

[UB] Generell lässt sich feststellen, dass Stegotext-Daten eine erhöhte Anzahl an nicht-druckbaren bzw. ähnlich aussehende Zeichen im Text aufweisen, die mittels einer Buchstabenanalyse identifiziert werden können. Dies führt zu einer erheblichen Vergrößerung der Dateigröße um ein Vielfaches im Vergleich zur Größe der geheimen Nachricht. Beim Austausch von Buchstaben durch Homoglyphen und der Verwendung von unleserlichen Homoglyphen gilt dasselbe Prinzip. Der wesentliche Unterschied besteht darin, dass hierbei deutlich mehr Symbole ausgetauscht werden, von denen jedes einen eigenen Charcode besitzt.

In Bezug auf Tools, die die Erzeugung von natürlich wirkendem Text ermöglichen, ist die Anwendung der Buchstabenanalyse nicht möglich. Diese Methoden ersetzen keine nicht-druckbaren Zeichen, Buchstaben oder Homoglyphen. Daher erfordert die Analyse solcher Texte eine tiefere sprachliche Untersuchung.

Literaturverzeichnis

@misc{ovgu01,

  author =       „J. Dittmann, C. Krätzer“,

  year =         2024,

  title =        „Vorlesungsfolien ‚Digitale Selbstverteidigung‘. FIN/OVGU Magdeburg, Wintersemester 2023/2024“,

  pages =        „28-28“,

}

@misc{email01,

  author =       „Prof. Dr. Mesut Güneş“,

  year =         2023,

  title =        „Chapter 6: Application Layer – Email. FIN/OVGU Magdeburg“,

  pages =        „5-14“,

}

@misc{enrondb01,

  author =       „verschiedene Enron Mitarbeiter“,

  year =         „2015“,

  month =        may,

  title =        „Enron Email Dataset“,

  lastaccessed = „21.12.2023“,

  url =          „https://www.cs.cmu.edu/~enron/“,

}

@misc{buttugly01,

    author = „IronGeek“,

    year =“2023″,

    title=“Unicode Text Steganography Encoders/Decoders“,

    note=“Butt Ugly Latin Wide Version“,

    lastaccessed = „23.12.2023“,

    url = „https://www.irongeek.com/i.php?page=security/unicode-steganography-homoglyph-encoder“,

}

@misc{advance01,

    author = „IronGeek“,

    year =“2023″,

    title=“Unicode Text Steganography Encoders/Decoders“,

    note=“More Advanced Unicode Stego“,

    lastaccessed = „23.12.2023“,

    url = „https://www.irongeek.com/i.php?page=security/unicode-steganography-homoglyph-encoder“,

}

@misc{steggit,

    author = „Geezee“,

    year =“2015″,

    title=“Steg“,

    lastaccessed = „23.12.2023“,

    url = „https://github.com/geezee/steg“,

}

@misc{thunderbird,

    author = „Mozilla Foundation“,

    year =“2024″,

    title=“Thunderbird“,

    lastaccessed = „20.01.2024“,

    url = „https://www.thunderbird.net/de/“,

}

@misc{libreoffice,

    author = „The Document Foundation“,

    year =“2024″,

    title=“Libre Office“,

    lastaccessed = „20.01.2024“,

    url = „https://de.libreoffice.org/“,

}

@misc{selenium,

    author = „SeleniumHQ“,

    year =“2024″,

    title=“Selenium“,

    lastaccessed = „20.01.2024“,

    url = „https://github.com/SeleniumHQ/Selenium“,

}

@misc{python,

    author = „Python Software Foundation“,

    year =“2024″,

    title=“Python“,

    lastaccessed = „20.01.2024“,

    url = „https://www.python.org/“,

}

@misc{snow,

    author = „Matthew Kwan“,

    year = „2013“,

    title = „Snow“,

    lastaccessed = „21.01.2024“,

    url = „https://darkside.com.au/snow“

}

@misc{snowdescription,

    author = „Matthew Kwan“,

    year = „2013“,

    title = „Snow Description“,

    lastaccessed = „21.01.2024“,

    url = „https://darkside.com.au/snow/description.html“}

@misc{snowfunctions,

    author = „Matthew Kwan“,

    year = „2013“,

    title = „Snow Download“,

    lastaccessed = „21.01.2024“,

    url = „https://darkside.com.au/snow/snow.zip“}

@misc{meteor,

    author = „Gabe Kaptchuk, Tushar Jois, Matthew Green, Avi Rubin“,

    year = „2021“,

    title = „Meteor“,

    lastaccessed = „21.01.2024“,

    url = „https://meteorfrom.space/“

}

@misc{meteordemo,

    author = „Gabe Kaptchuk, Tushar Jois, Matthew Green, Avi Rubin“,

    year = „2021“,

    title = „Meteor Demo“,

    lastaccessed = „21.01.2024“,

    url = „https://colab.research.google.com/gist/tusharjois/ec8603b711ff61e09167d8fef37c9b86“

}