[Mini-WB] Verschlüsselungs-Algo umkehren

Den einzigen Grund warum du nicht die Umkehrung rausrückst ist, weil du es nicht selber schaffst und andere es machen sollen

Ich sag doch nichts, ich finds gut das du das für die Community hier bereitstellst.

Vielleicht kannst du ja noch ein paar weitere Beispiele der Verschlüsselung anbieten, sodass das Schema ein wenig 'einfacher' zu Lösen ist.
Z.B. würden mir ggf. die folgenden Zeichenketten helfen:
"a"-> ?
"A"-> ?
"p"-> ?
"P"-> ?
"PP"-> ?
"pp"-> ?
"papapapapapa" -> ?
"PAPAPAPAPAPA" -> ?
(...oder weitere Zeichenketten deiner Wahl)

Schätzt du den Schwierigkeitsgrad eher als niedrig oder als potentiell sehr hoch ein?

Da passt was nicht. Aus dem 13 char string wird ein 10 char string?
Ich denke da gehen Daten verloren

Zitat von monkey

Ich denke da gehen Daten verloren

Oder der String wird einfach komprimiert.

Hi,

Zitat

Da passt was nicht. Aus dem 13 char string wird ein 10 char string?
Ich denke da gehen Daten verloren

Welche Daten sollen den da "verloren" gehen?
Wenn er als zu verschlüsselnde Zeichen nur die Ascii-codes bis 127 zulässt, dann spart er an jedem Byte ein Bit (das MSB) ein, da dieses völlig unerheblich ist!
Somit per se schon 12% weniger Daten, nur Aufgrund der Vorgabe!
Und wenn er nun die 7-Bit Zeichen bitweise aneinanderhängt und als 8-Bit String ausgibt, hat er schon eine Verschlüsselung, auf die kaum einer kommt^^, s. hier.

Genauso könnte man übrigens einfach willkürlich (Schlüssel^^) Bits in die Zeichen einfügen, der "String wäre nur 12% länger aber nicht dekodeirbar, da "zuviele" Daten im zu dekodierenden String enthalten sind. Hmmmm, ich mach da mal ein Beispiel^^

Die Stringlänge wird kürzer, die (relative) Redundanz steigt. Da keine seltsamen Zeichen vorkommen gehe ich davon aus, dass keine Bitzerlegung und anschließendes Zusammensetzen stattgefunden hat. Bei einer Kompression fällt die Redundanz (irgendwann nicht mehr verlustfrei komprimierbar). Die Stringlänge fällt -> Es muss komprimiert worden sein. Irgendwie ergibt das ganze für mich einen großen Widerspruch.

Einzige logische Erklärungen:
1. Datenverlust
2. Sehr seltener Zufall (Redundanzsteigerung trotz Kompression ist sehr unwahrscheinlich)
3. Triviale Lösung

[autoit]

Global $x = 'Hello, World!'

[/autoit][autoit][/autoit][autoit]

ConsoleWrite('Crypt: ' & _Crypt($x) & @CRLF)
ConsoleWrite('DeCrypt: ' & _Decrypt(_Crypt($x)) & @CRLF)

[/autoit][autoit][/autoit][autoit]

Func _Decrypt($s)
Return StringReplace($s, 'qrHgq"pdpp', 'Hello, World!', 0, 1)
EndFunc

[/autoit][autoit][/autoit][autoit]

Func _Crypt($s)
Return StringReplace($s, 'Hello, World!', 'qrHgq"pdpp', 0, 1)
EndFunc

[/autoit]

lg
Mars

Mars das ist falsch.

PainTain meinte das die Crypt-Funktion 32 Zeilen lang sei oder so ähnlich, und nein das brauchst du nicht mit Kommentaren auszuschmücken um 32 Zeilen zu erreichen
Selbst wenn Daten verloren gehen, kann man die Funktion zum Daten verlieren à PainTain-Style erstellen.

Wenn er die Crypt Funktion hat, dann kann er sie uns ja zeigen?! - Daraus kann man dann ohne Probleme ne Decrypt Funktion machen

Wenn man den 1. Thread richtig gelesen hätte dann wüsste man das man auch daran knobeln soll
Was wäre das für eine Herausforderung das umzukehren sofern es eine lineare Encryption ist.

Oder PainTain hat ein Script gebastelt welches seinen String durch WinRar durchjagt und das Ergebnis anzeigt
Aber das ist natürlich unwahrscheinlich.

Ich habe das richtig gelesen. Und meine (Triviale) Lösung reicht aus um den in Post 1 gegebenen String zu entschlüsseln.
Es gibt in der Mathematik eine ganz einfache Sache. Man kann nur Formeln aufstellen wenn man genügend Anhaltspunkte hat.
Z.b. gehen unendlich viele Funktionen vom Typ f(x) = ax² + bx + c durch den Punkt (7/3). Es ist unmöglich anhand eines Punktes die richtige Funktion zu bestimmen.
Genauso gibt es unendlich viele Lösungen für den String in Post 1. Ich bin jetzt kein Experte, aber ich glaube es ist unmöglich ohne weitere Anhaltspunkte etwas herauszufinden.
lg
Mars

Ist einer von euch denn ein so guter Mathematiker, dass er weiß, wie viele verschlüsselte Begriffe man für die Entschlüsselung braucht?
Ich denke, das müssten ziemlich viele sein, um wirklich auf ein nicht nur zufällig passendes System zu kommen.

Schreib für den Anfang mal 10 weitere verschlüsselte Texte.

Ich würde mir entweder mehr Beispiele wünschen, oder eine Art BlackBox, die wir selber mit beliebigen Eingaben füttern können ohne den Algorithmus vor Augen zu haben.
Sofern man das Verfahren bei Kenntnis des Verschlüsselungsverfahrens knacken kann (z.B. Caesar-Chiffre), ist es wohl für AutoIt nur suboptimal geeignet

@jjj : Man kann nicht bestimmen wieviele (endliche) Begriffe man braucht um das unbekannte Verschlüsselungsverfahren und die zugehörige Entschlüsselung zu ermitteln.
Ein einfaches Beispiel wäre, dass ein Text bis zum 1000sten Zeichen mit einer +1 Caesar-Chiffre 'verschlüsselt' wird, aber die darauffolgenden, also 1001, 1002 etc. mit einer +2 Caesar-Chiffre verschoben werden.
Wenn das Verschlüsselungsverfahren unbekannt ist, hängt die Menge der Entschlüsselungsverfahren von den gegebenen Eingabe->Ausgabewerten ab. Wären diese nur z.B. 100-stellig, so würde man wohl vermutlich auf die Caesar-Chiffre kommen. Sind mehr Beispiele gegeben, so würde man wohl den Verdacht - da kein Gegenbeispiel existiert - weiter verfolgen und als Lösung vorschlagen. Sicher kann man sich aber nur nach einer ausschöpfenden Suche sein, d.h. man probiert alle Eingaben aus und wertet für sich das verschlüsselte Ergebnis aus. Nur stellt sich hier die Frage : Wie viel willst du ausprobieren? Alle Kombinationen mit 1-10 Zeichen? 1-100? 1-1000? Bis dahin scheint alles richtig zu sein. Die 1001 hätte in diesem plakativen Beispiel erst die Theorie verworfen... Aber für das 'Ausprobieren' mithilfe der ausschöpfenden Suche (->Bruteforce) würde uns zumindest eine Schnittstelle fehlen, sodass wir (zumindest stichprobenartig) unsere Eingaben testen können.

Stimmt, aber ich bin jetzt davon ausgegangen, dass jede Stelle nah dem gleichen System verschlüsselt wird.
Also maximal Enigma-Niveau. Viel komplexer kann es in der länge ja kaum sein.

Lade einfach mal dein kompiliertes Script hoch.

Zitat von jjj

Lade einfach mal dein kompiliertes Script hoch.

Skripte zu dekompilieren ist keine Kunst, ich würde daher eher eine Internetseite vorschlagen. Dadurch wäre der Algorithmus vorerst sicher.

Ne Internetsite ist dafür aber etwas aufwändig.
Und
Passt jetzt vielleicht nicht zum Thema, aber wo bekommt man den einen Dekompiler her?

Zitat von jjj

Passt jetzt vielleicht nicht zum Thema, aber wo bekommt man den einen Dekompiler her?

Stimmt, passt nicht zum Thema, ich schlage aber trotzdem einfach mal Google vor. Sowas ist außerdem gegen die EULA von AutoIt sowie in beiden Foren verboten, nur mal so zur Info.

Zitat von PainTain

(Ich hoffe, dass das kein Hashing-Algorithmus ist )

Wäre auch noch eine Variante, Mars.
Ich denke ohne dass wir den Crypt Algorithmus mal gesehen haben kann hier keiner irgendwas machen, denn sofern es wirklich ein Hash Algorithmus ist (was evtl eine logische Erklärung wäre), dann wäre das relativ sinnlos
€:
Wenn Daten verloren gehen wäre das noch ein Grund für eine Hash Funktion. Immerhin ist der Hash ... bit lang, und die Datei / Der String wesentlich größer / länger