Text mit unbekannter Codierung entschlüsseln.

[tr909]

Moin. Ich habe folgendes Problem. Ich habe ein Programm das Einstellungen codiert in eine Textdatei ablegt. Da ich dort gerne eigene Einstellungen durch ein externes Programm einfügen möchte, wüßte ich gerne den Algorithmus. Leider weiß ich nicht wie es kodiert ist. Sieht teilweise aus wie base64, oder etwas ähnliches. Scheint es aber nicht ganz zu sein. Ich habe auf jeden Fall die Möglichkeit beliebigen Klartext in Codetext umwandeln zu lassen. Gibt es ein Tool oder sonst eine Möglichkeit dahinter zu kommen womit/wie es kodiert ist? Bei Bedarf könnte ich ja mal ein paar beispiele posten.

Gruß
tr909

[Tormentor32]

Im Film klappt das immer...

Mal ehrlich, wenn du nicht weißt, mit welcher Methode das verschlüsselt wurde, dann kannst dus doch nur durch ausprobieren rauskriegen...

Und die Einstellungen sind sicher nicht zum Spass verschlüsselt abgelegt ;-)

[arbu man]

Im Prinzip nicht... Vielleicht wird das ganze ja noch per AES o.ä. verschlüsselt.
Du kannst aber Testen ob die Text länge, gleich bleibt (wird aus "Das ist ein Test" ein String in der gleichen Länge). Damit kannst du fest stellen ob das System komprimiert, verschüsselt oder denn Text anders (verlängert) darstellt.

Weiterhin kannst du dann testen ob sich Textteile wiederfinden lassen. Beispielsweise codierst du einen Text in den ein Wort oft vorkommt ("Das ist ein Test, der Test soll etwas Test artiges sein") im Ergebnis könntest du nun eine Zeichenfolge oft identifizieren. Damit kannst du vielleicht verstehen sie der Algo arbeitet.

Natürlich kannst du auch einfach Codierungsarten URL-Encode, Base64, Hex testen, also praktisch BruteForce.
Aber ein Universal rezept ist mir nicht bekannt.

mfg, Björn

Edit=OT:

Zitat:

Im Film klappt das immer...

Natürlich deswegen ist es auch ein Film, der vertippt man sich nie und hackt einen Computer in Sekunden, und am besten man kommt mit jeden System sofort zurecht :)

[Nuclear-Ping]

Poste doch mal Beispiele. Ohne die muss man die Kristallkugel bemühen und die is grade in der Werkstatt. ;)

[tr909]

Hier mal ein paar Beispiele :

Zitat:

1234567890 -> EAAEeVFYUFFiSURfU1VFVhsEMTAC
0987654321 -> EQsPelJbU1ppSEVeUlREVxoFMTAC
abcdefghijklmnopqrstuvwxyz -> QFBUKQEIAAEyEx4CDwobF1tHUkZCOxMWHhMyNgI=
zyxwvutsrqponmlkjihgfedcba -> W0tPOhIbExopCAUBDAkYDEBcSVVRKAANBQgyNgI=
abcdefg1234567 -> QFBUKQEIAFhpSkFbVFMVBktUMTQC
zyxwvu654321 -> W0tPOhIbUVxvSkdfGB4OHVBPMTIC

Code:

123456789012345678     -> EAAEeVFYUFFiSURfU1VFVhsEMTAC
1234567890123456789    -> EAAEeVFYUFFiSURcUVBBUR0NGDE5Ag==
12345678901234567890   -> EAAEeVFYUFFiSURcUVBBUR0NGAIyMAI=
1234567890123456789012 -> EAAEeVFYUFFiSURcUVBBUR0NGAIGfzIyAg==

Ich habe mal zum Test einen Text mit base64 codiert und eingefügt. Dann kommt beim Programmstart eine Fehlermeldung das der text ungültig ist. Dabei wird der text entschlüsselt angezeigt, also scheint es wohl etwas mit base64 zu tun zu haben.

Gruß
tr909

[DGL-luke]

dann könnte es eine einfache translationsverschlüsselung sein, die über das komplette byte (den kompletten EASCII-Zeichensatz) geht und dann mit base64 enkodiert wird, um es lesbar / per ASCII übertragbar / in INI-Dateien speicherbar zu halten.

Entschlüssele das ganze (aus base64) und dann kannst du mal mein textanalyse-prog drüberlaufen lassen. der char, der am häufigsten vorkommt, ist dann wahrscheinlich das "e". wenn du dann alle buchstaben um so viel verscheibst, wie differenz zwischen dem ord-wert von "e" und dem gefundenen zeichen ist.

Eine known-plaintext-attack wär dann natürlich auch einfach.

[tr909]

hmm. Also aus
GebenSiehierdenTexteindenSieanalysierenwollen wird
ZldVKAo9Dgx7ERwLEAARCX5QWUZSJAoKAgcIEBAPDAUYHllcRE BSIxMBCwU+FzQ2Ag==

Wenn ich das base64-decode und das Ergebnis durch die Textanalyse schicke sind alle Zeichen die vorkommen genau mit 7% vertreten (bzw. 2,4 und 6 % wenn ich den text per c&p einfüge). Also nicht sehr hilfreich :( Aber zum Glück ist ja bald Wochenende. Dann habe ich Zeit :cry:

[negaH]

Hi

hast Glück bzw. Pech ;)

Code:

123456789012345678     -> EAAEeVFYUFFiSUR fU1VFVhsEMTAC
1234567890123456789    -> EAAEeVFYUFFiSUR cUVBBUR0NGDE5Ag==
12345678901234567890   -> EAAEeVFYUFFiSUR cUVBBUR0NGAI yMAI=
1234567890123456789012 -> EAAEeVFYUFFiSUR cUVBBUR0NGAI GfzIyAg==

Hinter der Base64 Codierung muß eine Veschlüsselung stecken, sie hat folgende Eigenschaften

1.) es ist eine Blockverschlüsselung, das erkennt man oben bei den Leerzeichen die ich eingefügt habe. Blockverschlüsselungen sind im allgemeinen sicherer als Stromverschlüsselungen. Pech gehabt.

2.) die Blockgröße dieser Verschlüsselung dürfte 8 oder 16 Bytes sein, eher 16 Bytes. Peck gehabt, lässt sich nicht so leicht knacken.

3.) es wurde immer ein festes Passwort benutzt, Glück gehabt. Normalerweise würde man das Passwort mit Zufall in einen Sessionkey umwandlen. Das führt zu einer Vergrößerung der Datenmenge und zu dem Fakt das die gleichen String immer andere Resultate liefern. Also Glück gehabt, der Programmier des Algos. hat geschlampt.

4.) normalerweise würde man die Nachricht vor dem Verschlüseln mit Zufall am Anfang expandieren. Dann verschl. man beides in einem Rutsch. Auch hier würde die Datengröße ansteigen und der Output jedesmal anders sein. Glück gehabt das ist hier nicht der Fall ;)

5.) der 1. String verhält sich merkwürdig

7.) sollten die Daten nicht ein Mehrfaches der Blockgröße sein, sprich zb. 9 statt 8 Bytes oder 17 statt 16, so benutzt der Algo. ein Padding -> Cipher Text Stealing um den letzten unvollständigen Block zu verschlüsseln. Das erkennt man am den Daten wenn man sie nach binär umwandelt an Hand des letzten Datenblockes. Er unterscheidet sich komplett zu den anderen Strings, statt wie bei den vorherigen Datenblöcken identisch zu sein.

6.) versuche nun mal das zu verschlüsseln

Code:

12345678
11111111
22222222

123456781
111111111
222222221

1234567812345678
1111111111111111
2222222222222222

12345678123456781
11111111111111111
22222222222222222

12345678123456781234567812345678
11111111111111111111111111111111
22222222222222222222222222222222
11111111111111112222222222222222
22222222222222221111111111111111

An hand deren Outputs können wir die reale Blockgröße herausfinden.
Die Strings mit gleichen Zeichen sollten in jedem Datenblock unterschiedliche Werte ergeben. Also zb. 11111111 sollte vereschl. binär für die 1. Eins ein anderes Byte liefern als für die 2. Eins.
Mit den Strings 11111111111111112222222222222222 und 22222222222222221111111111111111 testen wir bei einem Blockcipher mit 16 Bytes Blockgröße ob die Blöcke untereinander verknüpft sind. Sollte das der Fall sein so würden die 2'er Zahlen in den Blöcken durch unterschiedliche Bytes codiert sein. Sollte das nicht der Fall sein, Glück gehabt, wir haben es fast geknackt. Denn dann würde der erste Block mit Einsen identisch mit dem 2. Block von Einsen aus dem 2. String sein. Der Programmierer hat mist gebaut.
Denn dann brauchst du nur alle 16 Zeichnen Strings die du benutzen möchtest mit der Software einmal verschlüsseln, daraus deine Strings zusammenbauen und in der INI speichern, ohne den Algo. noch das Passwort zu kennen.

Gruß Hagen

[tr909]

Ich habe die Werte mal verschlüsselt und es ist folgendes heraus gekommen.

Delphi-Quellcode:

12345678               ->   EAAEeVFYUFFqSERfU1VFVhsEOAE=
11111111               ->   EAMGfFVfVlhqSERfU1VFVhsEOAE=
22222222               ->   EwAFf1ZcVVtpS0dcUFZGVRgHOAE=

123456781               ->   EAAEeVFYUFFqSERfU1VFVhsEOQE=
111111111               ->   EAMGfFVfVlhqSERfU1VFVhsEOQE=
222222221               ->   EwAFf1ZcVVtpS0dcUFZGVRgHOQE=

1234567812345678            ->   EAAEeVFYUFFqS0ZaV1JDXxsEMTYC
1111111111111111            ->   EAMGfFVfVlhqSERfU1VFVhsEMTYC
2222222222222222            ->   EwAFf1ZcVVtpS0dcUFZGVRgHMTYC

12345678123456781            ->   EAAEeVFYUFFqS0ZaV1JDXxsEMTcC
11111111111111111            ->   EAMGfFVfVlhqSERfU1VFVhsEMTcC
22222222222222222            ->   EwAFf1ZcVVtpS0dcUFZGVRgHMTcC

12345678123456781234567812345678   ->   EAAEeVFYUFFqS0ZaV1JDXxsHEgYCe1NWVltoTUBYVVwzMgI=
11111111111111111111111111111111   ->   EAMGfFVfVlhqSERfU1VFVhsEEAMGfFVfVlhqSERfU1UzMgI=
22222222222222222222222222222222   ->   EwAFf1ZcVVtpS0dcUFZGVRgHEwAFf1ZcVVtpS0dcUFYzMgI=
11111111111111112222222222222222   ->   EAMGfFVfVlhqSERfU1VFVhgHEwAFf1ZcVVtpS0dcUFYzMgI=
22222222222222221111111111111111   ->   EwAFf1ZcVVtpS0dcUFZGVRsEEAMGfFVfVlhqSERfU1UzMgI=

Derweil versuche ich mal das nachzuvollziehen was du gemacht hast.
Der Algo soll wohl auch nicht sehr sicher sein, da er nur auf Geschwindigkeit optimiert ist und eigentlich nur dazu dienen soll das nicht jeder direkt sehen kann was drin steht.

Gruß und Dank
tr909

[negaH]

Zitat:

Der Algo soll wohl auch nicht sehr sicher sein, da er nur auf Geschwindigkeit optimiert ist und eigentlich nur dazu dienen soll das nicht jeder direkt sehen kann was drin steht.

Woher weist du das ? Hast du noch wichtige Informationen di du uns nicht veraten hast ? Ich möchte mich nur sehr ungern mißbrauchen lassen, nur weil ein Freund von dir einen primitiven Cipher entwickelt hat und nicht selber in der Lage ist das zu kryptoanalysieren. Immerhin ist es schon ein bischen Arbeit.

Nungut, es gibt ein par Auffälligkeiten die untypisch für eine sicherer Verchlüsselung sind.

1.) Die Blockgröße ist nicht klar definiert
2.) die Nachricht wird vor oder durch die Verschlüsselung um par Bytes expandiert, zb. eine Prüfsumme oder igendwelche andere Daten wie Recordtype oder so werden mit in den Datenblock eingerechnet. Das erkennt man an den letzten par Bytes, sie sind immer gleich.
3.) es gibt keine Abhängigkeit der Blöcke untereinander

Mal ein Beispiel, ich habe die MIME64 Strings in HEX umgewandelt.

Code:

11111111111111112222222222222222   -> 1003067C555F56586A48445F5355 4556 1807 1300057F565C555B694B475C5056 3332 02
22222222222222221111111111111111   -> 1300057F565C555B694B475C5056 4655 1B04 1003067C555F56586A48445F5355 3332 02

11111111111111111111111111111111   -> 1003067C555F56586A48445F5355 4556 1B04 1003067C555F56586A48445F5355 3332 02

Schau dir mal ganz genau die Daten an. Du wirst erkennen das die 11111'en der 1. Zeile am Anfang identisch kodiert werden in der 2. Zeile im 2. Block. Das Gleiche gilt für die 2222'er. So ein Block coiert aber nur 14 Ziffern identisch, danach folgen 2 Bytes die sich von der Blockposition her unterscheiden und danach nochmal par Bytes, bei denen ich annehme das sie im Algo. nur Füller sind.

Nungut es ist also zumindestens schonmal ein Angriff möglich. Wir können ganz gezielt aus einem langen 1111'er String wie in der 3. Zeile einen String wie in der 1. oder 2. Zeile zusammen bauen.

Stelle dir das so vor:
Wir wissen das das Program eine Banküberweisung mit dem Algo. verschlüsselt. Wir wissen auch das in den ersten 16 Bytes die Summe und Bankdaten kodiert sind und im 2. Datenblock der Empfänger dieser Summe. Angenommen unser Empfänger wäre die Kontonummer 2222222222222222. Unsere eigene Kontonummer ist die 1111111111111111. Wir können also die Banküberweisung (1. Zeile) so fälschen und abändern das aus der Kontonummer 22222222222 die Kontonummer 11111111111111 wird. Das Geld geht also auf unser Konto.
Der Algo. ist damit defakto unsicher.

Jetzt musst du härter analysieren. Du musst rauskriegen was es mit den zusätzlichen Datenbytes auf sich hat, sind es Prüfsummen oder zus. Recordfelder ?
Am besten du fängst an eine größere Menge an Daten zu sammeln. Zb. indem du das verschl. und analysierst

Code:

1
11
111
1111
11111
111111
1111111
usw. bis du 64 Einsen codiert hast.

2
22
222
2222
usw.

3
33
333
usw.

und den MIME64 String in einen binären umwandelst und diesen in HEX konvertierst. MIM64 ist für die Analyse ein schlechtes Format.
Dann zählst du ab ob die Nachricht Blockweise oder nur einmalig um einen feste Anzahl von Bytes expandiert wurde. D.h.

a.) sind es immer +X Bytes mehr in den verschl. Daten unabhängig von deren Datenmenge ?
b.) sind es DataLength div BlockSize *X Bytes an verschl. Daten mehr, also werrden zb. nach 16 Bytes pro Block noch 2 zusätzlich eingefügt ?

Wenn du das raushast, weist du ob eine Prüfsumme Blockweise oder Nachrichtenweise angehängt wird. Auf alle Fälle ist es auffällig das am Ende der verschl. Nachricht immer die gleichen Bytes stehen.

Es ist aber jetzt schon mit hoher Sicherheit ersichtlich das es sich um keinen guten bzw. sicheren Algo. handlen kann. Dazu hat der Programmierer zu viele gravierende Fehler gemacht. Wenn man es richtig macht würde man nicht durch die Analyse von so wenigen Testdaten die Informationen herausbekommen die wir jetzt schon rausgefunden haben. Ich meine nach 30 Minuten effektiv.

Gruß Hagen


Gruß Hagen