Text mit unbekannter Codierung entschlüsseln.

[Phoenix]

Geil. Kryptoanalyse live.
*Threadabbonierunddazulern*

[Nuclear-Ping]

Ja, ich les hier auch schon die ganze Zeit gespannt mit. 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 von Phoenix:

Geil. Kryptoanalyse live.
*Threadabbonierunddazulern*

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

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]