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

[Phoenix]

Geil. Kryptoanalyse live. :thumb:
*Threadabbonierunddazulern*

[Nuclear-Ping]

Ja, ich les hier auch schon die ganze Zeit gespannt mit. :D Echt interessant, obwohl ich nur Bahnhof verstehe.

[brechi]

Sag mir lieber mal um welches Programm es sich handelt, oder upp die exe etc. Dann crack ich dir das eben. Geht wahrscheinlich schneller wenn ich mir den assembler code anschaue als wenn hagen von input und output daten den algo zurückverfolgen will ;)

[Nuclear-Ping]

Aber nur, wenn du das auch so schön beschreibst wie Hagen hier. ^^

Ich glaube damit bewegst du dich aber schonwieder am Rande der Legalität.

[brechi]

Naja ich cracks ja nicht, ich shcua nur was die benutzen und sag dann um welche verschlüsselung es sich handelt und wie das PW etc. ist.

[negaH]

Zitat:

Sag mir lieber mal um welches Programm es sich handelt, oder upp die exe etc. Dann crack ich dir das eben. Geht wahrscheinlich schneller wenn ich mir den assembler code anschaue als wenn hagen von input und output daten den algo zurückverfolgen will

Das wäre in der Tat einfacher in diesem Falle. Allerdings zeigt schon die bloße Analyse das es zumindest teilweise knackbar ist, bzw. das der Aufwand dafür ungleich geringer sein wird als bei einer guten Implementierung.

Ich hatte aber nicht vor nun von Anfang bis Ende das Ding zu analysieren, immerhin will der OP das wissen und muß sich demzufolge auch damit selber befassen. Ich werde nur Ansätze und Hinweise geben.

Auf alle Fälle ist das Design anfällig. Ich vermute das die zusätzlichen Bytes entweder

a.) Prüfsummen sind
b.) Block-Identifikatoren sein könnten
c.) zusätzliche Informationen aus dem internen Registern des Ciphers sind, dh. Redundanz zu den Inputdaten oder dem Passwort

In jedem Falle ist es für uns zusätzliche Information die wir benutzen können um das Ding zu knacken. Normalerweise versucht man strengsten zu verhindern das sowas passiert.
Zb. Fall c.) bedeutet das der Programmierer nach/vor jeden Datenblock zusätzliche Infos abspeichert die das Passwort kontinuierlich verändert. Also jeder Datenblock arbeitet mit einer veränderten Kopie des originalen Passwortes. Die zusätzlichen Bytes könnte benutzt worden sein um eben diese Passwort zu verändern. Das wären natürlich wertvolle Informationen für uns um das Passwort zu knacken. Dazu müssen wir aber herausfinden ob nun die Expansion der Datenmenge konstant zu Nachrichtengröße ist oder konstant zu der Datenlänge (Blöcken) der Nachricht ist. Sprich, werden nur Bytes am Ende der gesammten Nachricht drangehangen oder alle 16 Bytes ein par Bytes in den Ciphertext eingebaut.

Sind aber alles Hypothesen die man erst noch verifizieren müsste.

Gruß Hagen

[edit]
Quatsch erzähle ich da. Wir wissen ja schon das die gleichen Daten an unterschiedlicher Blockposition immer fast identisch verschlüsselt werden. Das widerlegt die Hypothese das das Passwort kontinuierlich Block für Block verändert wird. Nein, das Passwort ist immer gleich lang. Das spräche dafür das der Programmierer eine einfache XOR-Verschlüsslung mit dem Passwort gemacht hat, immer reihum sequentiell. Das würde auch erklären warum die Blockröße si unklar ist, also 14 Bytes statt 16 Bytes. Das Passwort könnte also durchaus exakt 14 Bytes o.ä. groß sein.

Der Test auf diese Hypothese müsste so aussehen das man mit zb. folgenden Daten experimentiert

Code:

123123123
112233112233112233112233
111222333111222333111222333111222333
111122223333111122223333111122223333111122223333
usw.

Falls das Paswort zb. 14 Zeichen lang ist und der Algo. wirklich nur per XOR oä. verschlüsselt und dabei einfach das Passwort rotiert, dann müssten wie mit obigen Testdaten ein Set finden bei dem die 1111 und 2222 und 3333 Blöcke identisch verschlüsselt wurden. Sollte dies der Fall sein wissen wir wie lang dieses Passwort ist. In diesem Falle wäre es KEIN Blockcipher mehr eher ein Streamcipher dessen kleinste Dateneinheit so lang wie das Passwort ist.
[/edit]

[TeronG]

IchAuchOT:

Zitat:

Zitat von Phoenix

Geil. Kryptoanalyse live. :thumb:
*Threadabbonierunddazulern*

Immer gut, wenn Hagen sich bei sowas einklinkt ^^ *zuPopkornGreif*

Zitat:

Zitat von brechi

Naja ich cracks ja nicht, ich shcua nur was die benutzen und sag dann um welche verschlüsselung es sich handelt und wie das PW etc. ist.

Aber unter 2 Seiten Ausführung /erklärung kommste uns nicht davon! ^^

[negaH]

Code:

111111111111111122....   -> 1003067C555F56586A48445F5355 4556 1807 ...
222222222222222211....   -> 1300057F565C555B694B475C5056 4655 1B04 ...

Auch auffällig ist das die Ciphertext Bytes sich nur wenig untrscheiden. Zb. aus der 1. Eins wird -> $10 und aus einer Zwei wird -> $13 usw.

Das könnte darauf hinweisen das der Algo. einfach an erster Position +3 Addiert, an zweiter -3 subtrahiert, dann +1 addiert. Diese Differnez kann entstehen wenn der Algo. einfach das Nachrichtenbyte mit dem Passwortbyte mulipliziert, modular zu 2^8.

Probiere doch mal 333333333333333333334444444444444444444 auch noch aus. Wenn die '3' an erster Position wieder um +-3 differiert zu der '2', dann haben wir ein Muster erkannt.

Sollte die Differenz '1' -> '2' = +3, aber '2' -> '3' = -3 sein so können wir davon ausgehen das es eine modulare Multiplikation ist.


Also nochmal das was wir an Daten benötigen

Code:

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

2
22
222
2222
usw. bis du 64 Zweien codiert hast.

3
33
333
usw. bis du 64 Dreien codiert hast

das machst du bis zum 'Z'
Dann noch

123123123
112233112233112233112233
111222333111222333111222333111222333
111122223333111122223333111122223333111122223333
usw. das machst du bist du 64 Einsen, Zweien, Dreien hast

Gruß Hagen

[tr909]

Also 333333333333333333334444444444444444444 wird EgEEflddVFpoSkZdUVdHVBkGEgEDeVBaU11vTUFaVlBAUx4BFQ YDMzkC d.h. es fängt mit $12 an

Für den Rest würde ich noch etwas Zeit benötigen.

*edit*
Oje, da hab ich am WE ja echt was zu tun um das nachzuvollziehen. Aber so lernt man wenigstens was. Das Programm um das es geht findet sich unter http://www.phraseexpress.com/de/.
Der Grund warum in die Konfiguration schreiben möchte ist folgender: Das Programm ist ja zum einfügen von Textbausteinen, etc. Nun möchte ich aus einer eigener Anwendung Kontext bezogen Textbausteine einfügen. Also z.B. die Kundendaten des aktuell geöffneten Kunden, unter immer dem gleichen Kürzel zur Verfügung stehen.
Hätte ich geahnt das es so aufwendig wird hätte ich wohl auch gar nicht gefragt (sondern wohl gewartet bis irgendwann die angekündigte Version mit nicht verschlüsseltem User-Content rauskommt ;)

Aber wie auch immer. Ich bin schon dankbar für die bisherige Hilfe und hoffe das ich daraus auch schon viel lernen kann. Und vielleicht gibt es hier ja auch noch eine Lösung. Es würde mir ja auch schon helfen wenn ich Daten reinschreiben kann ohne Algo/Pw zu kennen (sowas hatte Hagen ja weiter oben mal angedeutet)
*edit*

Gruß
tr909

[negaH]

- das Passwort ist 18 Bytes lang

- es wird bei Nachrichten > 18 Bytes immer wiederholt angewendet

- die letzten 3 Bytes eines Ciphertext (verschl. Text) ist die Länge der Nachricht -> 2 Bytes als ASCII + einem Abschlußbyte das nicht in ASCII gespeichert wird. Eine Länge von 100 ist also so codiert '00'+$03, eine Länge von 16 dann so '16'+$02. Dh. der Algo analysiert das letzte Byte, ist es $01 dann gelten nur das vorletzte ASCII Byte als Länge. Ist es $02 dann gelten die 2 vorherigen ASCII Zeichen als Länge, ist es $03 dann wird 100 + die vorletzten ASCII zeichen als Länge interpretiert, bei $04 müsste es also 200 + ASCII Zeichen die Länge sein.
Das ist eindeutig ein Zeichen das in führeren Versionen der Software die Länge der Texte begrenzt war. Später würde das erweitert. Um kompatibel zu bleiben wurde diese verrückte Codierung benutzt.

- die ersten 2 Bytes des "Passwortes" (wenn man von Passwort überhaupt reden kann) unterscheiden sich zu den anderen 16 Bytes des Passwortes

- die restlichen 16 Bytes des Passwortes scheinen einfache Operationen mit dem Passwort zu sein

- eine Nachricht die kürzer als 18 Bytes ist wird expandiert. Dazu wird die Nachricht einfach solang an sich selber rangehangen bis sie größer 18 Zeichen ist und dann auf 18 Zeichen gekürzt

Alles in allem eindeutig ein Algo. der "Security trough Obscurity" benutzt statt mathem. sicher zu sein.

So im Grunde fertig, diese Infos reichen um den Algo + Passwort nachzubauen. Jetzt muß man nur noch eine Lookup Tabelle bauen in der alle 256 zeichen zu den 18 möglichen Positionen des Passwortes gespeichert sind. Also ein Array[0..17, Byte] of byte. Nun lässt man im Program alle 256 Zeichen verschlüsseln, also 256 mal die String "0000000000000" alle 18 Zeichen lang bis zum String "ZZZZZZZZZZZZZ". Aus der Datei werden diese Daten geladen und daraus baut man diese Lookup Tabelle. Fertig.

Gruß Hagen

[edit]
- Passwort ist -> !27Mdngi[yunbdtg*5
- man findest diesen String merhfach in der EXE.
- die Verschl. ist einfach XOR mit dem Passwort

Delphi-Quellcode:

function Decrypt(const Data: String): String;
const
  Password: String = '!27Mdngi[yunbdtg*5';
var
  Len,I,J: Integer;
begin
  Result := TFormat_MIME64.Decode(Data);
  Len  := Length(Result);
  Len  := StrToInt(Result[Len -2] + Result[Len -1]) + (Ord(Result[Len]) - $02) * 100;
  SetLength(Result, Len);
  J := 1;
  for I := 1 to Len do
  begin
    Result[I] := Char(Ord(Result[I]) xor Ord(Password[J]));
    Inc(J);
    if J > 18 then J := 1;
  end;
end;

- Aus Decrypt('ZldVKAo9Dgx7ERwLEAARCX5QWUZSJAoKAgcIEBAPD AUYHllcREBSIxMBCwU+FzQ2Ag=='); wird -> GebenSie hierdenTexteindenSieanalysierenwollen
du hast uns also ein Leerzeichem im Text unterschlagen, du Sack ;)

Fazit: ohne die Software zu debuggen, rein aus der Analyse der Daten die die Software speichert, haben wir das Teil in 40 Minuten Zeitaufand geknackt. Schade war zu einfach.
FazitFazit:

Der benutzte Angriff der Kryptoanalyse nennt sich "Choosen Plain Text Attack". Man kann also frei den Plaintext -> zu verschl. Nachricht, wählen und den CipherText -> verschl. Nachricht analysieren. Das wurde möglich weil

1.) eine simple XOR Verschl. benutzt wurde
2.) das Passwort immer wiederholt ohne Änderungen und direkt mit der Nachricht benutzt wurde, es gibt also eine direkte Abhängigkeit des Paswortes zur Verschlüsselung
3.) aus dem Passwort vor der Verschl. kein mit Zufall umgerchneter Sessionkey benutzt wurde
4.) die Nachricht vor der Verschl. nicht mit par Zufallbytes am Anfang expandiert wurde

Punkt 3.) und 4.) stellten sicher das wir aus den Mustern des CipherText die Lönge das Passwortes, den Aufbau des Cipher -> Block/Stromverschl. und die 3 Endebytes, erkennen konnten. Hätte man Punkt 3.) und 4.) benutzt mit einem guten Blockcipher hätten wir keinerlei Chancen gehabt.
[/edit]

[negaH]

Achso, möchtest du das Passwort sehen ?

Öffne die Datenbank von der Softare und tausche irgend eine Description mit nachfolgendem Wert aus

AAAAAAAAAAAAAAAAAAAAAAAAMTgC

Das ist ein CipherText der aus 18x $00 Bytes besteht und am Ende eine Längensignatur von '18',$02 besitzt.
Da das Program eine XOR Verschlüsselung benutzt und diese Operation invers zu sich selber ist, wird der Algo. nach der Entschlüsselung uns das Passwort liefern, quasi frei Haus.

Übrigens ist das dann eine "Choosen Ciphertext Attack". Man kann also die verschl. Nachricht frei zusammenbauen und lässt diese Nachricht durch die Software wieder entschlüssen.
Benutzt nun der Algo. eine einfache XOR Operation mit dem Passwort so wird er aus einer $00 Bytes CipherText direkt das Passwort verraten. Sowas geht sogar offline.

Also

x xor y = y wenn x == 0 ist.

Gruß Hagen

[Nuclear-Ping]

Hehe, Freak (nicht böse gemeint). :coder:

[negaH]

Tja, und das war's dann. Hatte gehofft das sich der OP nochmal meldet und uns mitteilt ob das funktioniert hat.
Das sind solche Threads bei denen man die Lust verliert überhaupt noch irgendwas qualifiziert zu beantworten. Mir gehts halt so das ich ein positives Feadback sehr zu schätzen weis.

Gruß Hagen

[arbu man]

Ich fand es auf jeden Fall Eindrucksvoll wie du das gemacht hast, auch wenn ich nicht wirklich viel Verstanden habe, habe ich sehr gerne und interessiert mitgelesen.
Ich habe mich in letzter Zeit auch etwas mit dem Thema Verschlüsselung befasst aber nach diesen Thread hab ich meine eigene Verschlüsselung dran gegeben, die wäre wahrscheinlich auch schnell enttarnt, zumindest wenn jemand von deinen Kalibers es versucht.

mfg, Björn

[Relicted]

wow...
mehr kann man dazu nicht sagen...
hut ab hagen... bekommst das lob von der community :-)

aber der alternative lösungsweg von brechi würd mich jetzt auch noch interessieren :D los her mit der lösung und wie in der mathestunde damals in der schule: lösungsweg nicht vergessen! :-)

gruß
reli

[DeddyH]

Hut ab und verbeug. :thumb:

[tr909]

Sorry das ich noch nix dazu geschrieben habe. Vielen Dank an Hagen für die Hilfe. Bin noch nicht dazu gekommen deinen "Lösungsweg" nachzuvollziehen, aber es funktioniert einwandfrei. Ich werde dann in den nächsten Tagen noch eine Funktion zum encoden schreiben und dann bin ich wunschlos glücklich. Für die Zukunft gelobe ich dann Besserung bezüglich der Antwortzeiten.

Gruß und Dank sagt
tr909

[TheAn00bis]

Hab mir hier jetzt nicht viel durchgelesen, aber warum nicht über reverse engineering? Also exe in OllyDebug oder ähnliches, einen Haufen Breakpoints setzen, die Stelle finden, ab wo verschlüßelt wird usw.
Oder hab ich irgendwas verpasst?

[negaH]

Nein du hast nichts verpasst.

Aber für das Reverse Engineering braucht man um effizient zu sein als erstes ebenfalls eine Analyse. Ich schätze mal das ich mit der reinen Analyse der Daten schneller bin als ein geübter Engineer (Hacker) (40 Minuten insgesamt habe ich benötigt).

Davon abgesehen hat man beim Hacken meistens nur eine gepatchte Software und nicht zwangsläufig den benutzten Algo. gebrochen. Mit meiner Methode kann man nun ohne Änderung der Software eigene Daten ver/entschlüsseln.

Zitat:

Ich fand es auf jeden Fall Eindrucksvoll wie du das gemacht hast, auch wenn ich nicht wirklich viel Verstanden habe, habe ich sehr gerne und interessiert mitgelesen.

Tja, warum fragst du dann nicht genauer nach ?
Ich kann versuchen meine Erklärungen besser zu formulieren, wichtig ist doch nur das es am Ende auch verstanden wurde.

Zitat:

Ich werde dann in den nächsten Tagen noch eine Funktion zum encoden schreiben

Bin schon auf deine Lösung gespannt. Noch par Hinweise:

1.) oben schrieb ich das bei kurzen Strings < 18 Zeichen, der String durch wiederholung auf die Länge 18 expandiert und gekürzt wird.
Das scheint aber für dein Encoder nicht notwendig zu sein. Dh. die Software müsste auch mit zu kurzen Strings, 1 zu 1 kodiert, zurecht kommen

2.) die Verschlüsslungs Funktion ist identisch zur Entschlüsselungsfunktion. Einzigster Unterschied ist das bei der Verschlüsselung die letzten 3 Bytes (Länge) berechnet werden müssen, und bei der Entschlüsselung dann ausgelesen werden. Ansonsten ist der Sourcecode identisch.

Gruß Hagen

[Flare]

Zitat:

Zitat von TheAn00bis

Hab mir hier jetzt nicht viel durchgelesen, aber warum nicht über reverse engineering? Also exe in OllyDebug oder ähnliches, einen Haufen Breakpoints setzen, die Stelle finden, ab wo verschlüßelt wird usw.
Oder hab ich irgendwas verpasst?

Ich nehme mal an, dass genau dies brechi versuchen wollte. negaH hat es lieber über den logischen Weg versucht und das Passwort dann noch aus der Exe rausgelesen. Und bei der Geschwindigkeit, in der negaH das gelöst hat, würde ich sagen, dass beide Wege ihre Berechtigung haben. Vor allem müsste man, wenn man endlich die Stelle der Verschlüsselung gefunden hat, noch Assembler können, um den Verschlüsselungsalgorhythmus zu verstehen und umzukehren.


Flare

[negaH]

Zitat:

und das Passwort dann noch aus der Exe rausgelesen

Vorsicht das stimmt so nicht. Ich habe zuerst das Password regelgerecht krytoanalysiert ohne irgendwas mit der Software zu machen, ausser das sie mir par Testvektoren zur Verfügung gestellt hat.
Nachdem die Passwortlänge ermittelt war, bekannt war das sich das Passwort immer wiederholt, und erkannt hatte das es ein Streamcipher ist, habe ich das Passwort per Differentielle Analyse ermittelt. Auf den Verdacht hin das simples XOR benutzt wurde. Dazu benutzt man nur 2 Ciphertexte und verküpft sie per XOR. Danach habe ich mit der "Choosen Ciphertext Attack", oben den Wert AAAAAAAAAAAAAAAAAAA.., das Passwort durch die Sofwtare selber anzeigen lassen. Und erst dann fragte ich mich wieviel Knowhow hat der Programmierer in seiner Sofwtare investiert um wenigsten das Passwort vor Entdeckung/Veränderung zu schützen. Also mal schnell den HEX Editor geöffent und nach dem Passwort in der EXE gesucht. Es ist dort nicht geschützt, sofort lesbar, und an mindestens 10 Stellen gespeichert. Also nicht zentral nur einmal.
Das lässt vermuten das der Entwickler den gleichen Algo. für verschiedene Aufgaben benutzt, zb. auch für die Freischaltung der Software. Wollte man per Reverse Engineering das Ding knacken so hiese dies das man quasi den gleichen Algorithmus an 10 verschiedenen Stellen im Code knacken muß.

Wie gesagt ich bin nicht per "Trial&Error" auf die Suche nach dem Passwort gegangen, sondern per Kryptoanalyse.

Allerdings muß man auch eingestehen das das Ding wirklich leicht zu brechen ist. Das mag zwar für einen Laien nicht so sein, aber ein Profi wäre noch einiges schneller gewesen als ich. Das zeigt sich sehr schön hier im Thread. Meine ersten Vermutungen waren mindestens zu 50% falsch, einfach weil nicht genügend Daten vorhanden waren und weil ich selber nicht die logisch richtigen Schlussfolgerungen gezogen habe. Man kann also an Hand dieses Threads sehr gut beobachten wie man Vermutungen aufstellt, wie man überlegt mit welcher Methode man diese Vermutungen überprüfen kann, und die sich daraus ergebenden Schlussfolgerungen logisch so umsetzt das man immer mehr Informationen über das unbekannte System sammelt. Bis eben am Ende das Ding gebrochen ist.
Am Anfang vertrat ich die meinung das es eine Blockverschlüsselung sei, oder das das Passwort 16 Bytes lang wäre, oder das nach X Bytes an Daten immer Y Bytes an Prüfsumme oä. eingefügt sind. Das waren alles fehlerhafte Annahmen.

Nochwas: Ich habe auch schon andere System kryptoanalysiert, logisch irgendwie ;) Darunter auch "Freischaltung von Delphi" oder einige andere Tools die zb. mit Rainbow Technologies geschützt waren, bzw. sind ;) Deren Qaulität ist nicht viel besser, wenn auch komplexere Algorithmen benutzt werden. Also auch wenn ich die "Arbeit" des Programmierers kritisiere, so muß man das relativ betrachten und sagt nichts über die Fertigkeiten dieses Programmierers aus. Höchstens über dessen Priorisierung was er für wichtig erachtet.

Gruß Hagen

[tr909]

@Hagen
Die Hinweise für meine Lösung hätte ich nicht unbedingt gebraucht (hattest du ja vorher schonmal erwähnt). Aber nchmal Danke für die Zusammenfassung.

Und nun noch ein Tip.
Das in diesem diesem
Beitrag erwähnte "CrypTool - eLearning-Programm für Kryptologie" habe ich mir auch mal angeschaut und soweit ich es bis jetzt beurteilen kann, kann man damit einen guten Einblick in die Materie bekommen.

Gruß
tr909