Encrypted Packets - Decryption possibilities?

Hey there,

Presently, visiting network class in university and in a catch, I was interested in modifying custom/received/sent packets over a socket between server - client.
For some practice, I pulled out the game "PokeMMO" and analyzed received & sent packets.

I typed the letter 'A' in chat to see, if I recognize hex value 0x41 in ip datagramm.
It didn't work out so easily, so I thought, maybe they sending a session key in plaintext (that would be stupid) by logging into the game. So, the session key is used to encrypt ip packets, everytime a new connection established, ranomized a session key for the client connection. Also looked out for packets, which may be interesting. Nevertheless I failed pretty hard with my ideas and went back to sniff packets in chat.
Typed a multiple times letter 'A' in chat, whom leads me to different ip packets with variety payloads/data.
Does the server randomize for every ip packet an unique key? - Yes
Capable to reason the encryption routine? - Nope

What ideas do you come up with?
What kind of encryption algorithm is used nowadays for small, mmo project? or lets say, the common way to encrypt packets?
Its written in Java.

wenn du den ip verkehr mitschneidest wirds vermutlich mit ipsec gesichert sein, dann musst du wiederum unterscheiden mit welchen headern die ip pakete gesichert sind und und und...
vllt hilfts ja wenn du dich in die rfc's 4302 und 4303 einliest, denk du wirst aber eher schlechte karten haben die zu manipulieren.

schreib dir lieber mit c ne einfache socketanwendung die unverschlüsselt sendet und schneide da den verkehr mit

Quote:

Originally Posted by NotThatBad wenn du den ip verkehr mitschneidest wirds vermutlich mit ipsec gesichert sein, dann musst du wiederum unterscheiden mit welchen headern die ip pakete gesichert sind und und und... vllt hilfts ja wenn du dich in die rfc's 4302 und 4303 einliest, denk du wirst aber eher schlechte karten haben die zu manipulieren. schreib dir lieber mit c ne einfache socketanwendung die unverschlüsselt sendet und schneide da den verkehr mit  Spoiler lernst das aber noch genau im 4. sem in netzwerk- und systemsicherheit, das darf ich mir grad geben :D

Der Wiki-Eintrag wurde/wird mir auch als erste Anlaufstelle angezeigt, doch ich dachte, es sei hier nicht zutreffend... Hier mal das Zitat aus dem Eintrag...

Quote:

oder zum Schutz vor Replay-Angriffen eingesetzt werden.

Das erklärt definitiv auch meine obrigen Ergebnisse. Auf meinem Arch Linux habe ich mittels tcpdump und tcpreplay die IP Datagramme .pcap geloopt und versucht an den Server zu schicken...


Ich mag es zwar an Dingen zu verzweifeln, aber wenn man keine Anhaltspunkte hat.... nix gut.






Ich werd mich da mal einlesen, verzweifeln und erneut einlesen, da wird schon Schritt für Schritt Fortschritt gemacht

genau, auf den schutz gegen replay angriffe wollt ich raus.
die payload wird eben mit ner zufälligen nonce gehasht, und du kannst das nur decrypten wenn du die init-nonce + paketnummer rausfindest


jedenfalls viel glück

Quote:

Originally Posted by NotThatBad genau, auf den schutz gegen replay angriffe wollt ich raus. die payload wird eben mit ner zufälligen nonce gehasht, und du kannst das nur decrypten wenn du die init-nonce + paketnummer rausfindest  Spoiler frag doch mal beim heer nach, der hilft dir doch sicher gern bei sowas jedenfalls viel glück

Wait, wait, wait!
Ein Man-In-The-Middle Angriff, der von Anfang an den Packet-Verkehr mitschneidet und auch die Möglichkeit hat einzugreifen, ist immer möglich! Es gibt momentan keinen Algorithmus, der das unterbinden kann.

Dabei ist das Prinzip immer dasselbe:
Der MITM gibt sich als Server aus und gleichzeitig als Client. Damit muss er zwar eventuell ein bisschen was simulieren, aber das hält sich in Grenzen.

Die Verschlüsselung solcher Pakete basiert normalerweise auf simplen symmetrischen Verfahren. Besonders gerne werden XOR-Abkömmlinge ala XXTea-Crypt benutzt, weil schnell und einfach zu implementieren bei durchschnittlicher Sicherheit.

Schau dir am besten einfach mal den Java-Source an, der lässt sich ja schnell dekompilieren.

Das Dekompilieren kam mir auch in den Sinn, aber bisher NULL Erfahrung in dem Bereich. Wenn du aber mit der Idee hochkommst, dann wird es Zeit, sich das durchzulesen und dran zu arbeiten.

Durch das Dekomil. wird es sich zu erkennen geben, was fuer ein Algorithmus es ist. Bei symmentrischen Algorithmus habe ich schon meine Probleme bei der Programmierumsetzung bzw. das Cracken einer solchen Routine - Ein Kommilitone hat nämlich in dieser Woche eine Decryption Challenge gemacht (untersch. Encrypt. Algo.) Ab DES komme ich nicht mehr weiter...

Ich fang mal heute Nachmittag an, muss erstmal Decompiler auf Arch/Linux finden, dann kann die Arbeit mal langsam beginnen.... Danke

Quote:

Originally Posted by Shadow992 Wait, wait, wait! Ein Man-In-The-Middle Angriff, der von Anfang an den Packet-Verkehr mitschneidet und auch die Möglichkeit hat einzugreifen, ist immer möglich! Es gibt momentan keinen Algorithmus, der das unterbinden kann. Dabei ist das Prinzip immer dasselbe: Der MITM gibt sich als Server aus und gleichzeitig als Client. Damit muss er zwar eventuell ein bisschen was simulieren, aber das hält sich in Grenzen. Die Verschlüsselung solcher Pakete basiert normalerweise auf simplen symmetrischen Verfahren. Besonders gerne werden XOR-Abkömmlinge ala XXTea-Crypt benutzt, weil schnell und einfach zu implementieren bei durchschnittlicher Sicherheit. Schau dir am besten einfach mal den Java-Source an, der lässt sich ja schnell dekompilieren.

die möglichkeit einzugreifen bedeutet demnach zu entschlüsseln, daten zu verändern, und neu zu hashen und damit auch die prüfsumme anzupassen
nur wie genau soll das denn gehen?
wenn client und server in ner sicheren PKI per diffie-hellman die schlüssel ausgetauscht haben und dann mit diesem schlüssel per MD5 die HMAC bilden, wie willst du denn da eingreifen? du brauchst 1. die nonce, dann brauchst du den schlüssel und dazu kommt noch, dass MD5 eine einweg-funktion ist, dafür musst du dann pro nonce eine rainbow-table generieren

was ich nicht ganz versteh ist, wieso sich der MITM als client und server gleichzeitig ausgibt :confused: beim replay angriff gehts doch genau darum, authorisierte ip pakete abzufangen und und zu einem späteren zeitpunkt wieder zum server zu schicken, bspw. um sich als alice auszugeben

Quote:

Originally Posted by NotThatBad die möglichkeit einzugreifen bedeutet demnach zu entschlüsseln, daten zu verändern, und neu zu hashen und damit auch die prüfsumme anzupassen nur wie genau soll das denn gehen? wenn client und server in ner sicheren PKI per diffie-hellman die schlüssel ausgetauscht haben und dann mit diesem schlüssel per MD5 die HMAC bilden, wie willst du denn da eingreifen? du brauchst 1. die nonce, dann brauchst du den schlüssel und dazu kommt noch, dass MD5 eine einweg-funktion ist, dafür musst du dann pro nonce eine rainbow-table generieren was ich nicht ganz versteh ist, wieso sich der MITM als client und server gleichzeitig ausgibt :confused: beim replay angriff gehts doch genau darum, authorisierte ip pakete abzufangen und und zu einem späteren zeitpunkt wieder zum server zu schicken, bspw. um sich als alice auszugeben

Fakt ist, dass der Client und der Server irgendwann einmal die Schlüssel für das Public-Key-Verfahren austauschen müssen. Dafür gibt es zwei Möglichkeiten:
1. Beim Einloggen/Starten/whatever
2. Hardcodiert im Source-Code

Wenn man den Fall #1 hat, reicht es vollkommen so zu tun als wäre der MITM der Server und Client gleichzeitig, das heißt ganz konkret sieht das so aus:
Echter Client schickt seinen Teil des Public-Keys bzw. fordert den Server auf einen Key zu berechnen, basierend auf Parameter/etc. --> Packet wird losgeschickt --> MITM empfängt Packet und erzeugt einen Key wie es der Server tun würde --> MITM schickt ein neues, anderes Packet aber mit demselben Befehl an den echten Server (damit der MITM den Key vom Client nicht wissen/erraten muss und man so Sachen wie Zufall o.ä. vom Server nicht kennen muss, sondern nur den Prinzipiellen Algo) --> Server berechnet neuen Key und schickt es an den MITM zurück

Damit hat der MITM die Möglichkeit beliebig Pakete zu verschlüsseln und entschlüsseln, wie er lustig ist.

Bei 2. wird es erstmal ein klein wenig schwieriger, zumindest wenn man aus den Packets alleine wissen möchte was der Client sendet. Da der Client den Key aber fest im Code hat, braucht man das nicht zwingend, mit dem Key kann man ja automatisch alle Antworten vom Server entschlüsseln und so tun als wäre man der Client. Wenn man dann den wirklichen Inhalt der Pakete sehen will, muss man eben ein paar Funktionen hooken. Bzw. Bei Java den source decompilen und an der entsprechenden Stelle mitschneiden.

Viel einfacher wird das aber durch einen riesen Nachteil den Public-Key leider haben. Sie sind vergleichsweise langsam, was eine Kommunikation in Echtzeit fast unmöglichmacht. Daher geht man meistens den Weg, dass man nicht mit Public-Key-Verfahren direktverschlüsselt, sondern einen verschlüsselten Key für ein anderes Verfahren austauscht, welches aber schneller ist, z.b. AES. Das Spiel wird es höchstwahrscheinlich genau so machen. Das heißt:
Häng dich an die Stelle im Java-Source, der den Key sendet, lese ihn aus und dann hast du alles was du brauchst.

Aber viel wahrscheinlicher als die Theorie mit der PKI, ist dass das Spiel einfach eine simple Routine implementiert hat, welche keinen Schlüssel benötigt oder aber den Schlüssel hardcoded im Source enthält bzw. errechnet aus irgendeinem Session-Key.

Mir persönlich ist kein Free-To-Play game bekannt, welches den umständlichen Weg über PKI geht, denn eins muss einem klar sein: Das Hooken der entsprechenden Routine für Verschlüsseln im Binary ist immer möglich, genau so wie das Hooken der Entschlüsselungsroutine. Da das sowieso 90% der Programmierer machen und sich nur sehr wenige mit einem MITM-Angriff beschäftigen, lohnt es sich nicht da Ressource reinzu investieren.

Vorallem weil dieses Szenario auch seine Schwächen hat (siehe oben).

Edit:
Nur um noch einmal das Prinzip klar zu machen:
Solange man die Algorithmen herausfindet, die der Client benutzt (was immer möglich ist), kann man den Gegenpart dazu implementieren und selbst wenn Details falsch implementiert hat, solange man den MITM als Server und Client gleichzeitig betreibt ist es scheiß egal wie falsch die Parts sind. Da jeder Part ansich die "Fehler" des einen Parts nicht an den nächsten Part weitergibt, sondern so tut als wär alles richtig.

Das heißt solange man beide Seiten simuliert, kann man den kompletten Paket-Verkehr mitschneiden und verändern, ganz unabhängig von irgendwelchen Checks o.ä. die der Server zusätzlich macht. Zum allergrößten Notfall schneidet man einmalig den "Initialisierungs"-Packet Verkehr vom Clienten mit und benutzt in dem MITM-Client immer genau diese Initialisierungs-Packets.