bensch - Di 11.12.07 21:01
Titel: key einer AES-verschlüsselten Datei herausbekommen

---

hi

ist es möglich, den schlüssel herauszubekommen, wenn man eine gecryptete textdatei und die entschlüsselte textdatei hat? also ich hab hier die verschlüsselte datei, und die selbe datei nochmal im entschlüsselten zustand. kann man dadurch den verwendeten key herausbekommen?

folgender hintergrund: ich hab hier ein programm gefunden, dass bestimmte infos mittels AES verschlüsselt und dann in eine Datei speichert. nun möchte ich mit meinem programm auch solche verschlüsselten dateien erstellen, damit ich diese mit dem anderen programm laden kann. da ich aber den genauen schlüssel nicht habe, kann ich die infos ja nicht so verschlüsseln, dass das andere programm damit arbeiten kann...

kann man da was machen, oder ist es nicht so einfach möglich, den schlüssel so rauszubekommen?

mfg bensch

JayEff - Mi 12.12.07 10:23

---

Hier findest du die Arbeitsweise des AES: http://de.wikipedia.org/wiki/Advanced_Encryption_Standard Was du nun tun musst, ist herausfinden, wie die Umkehrfunktion lautet :shock:

Viel Erfolg :zustimm:

edit: Wenn ich mir das so ansehe, wird das eine heidenarbeit ... :shock:

bensch - Mi 12.12.07 11:00

---

hi

ja, das hab ich mir schon ein paar mal durchgelesen, aber so richtig durchsehen tu ich da nicht. ich wollte halt erstmal prinzipiell wissen, ob dies möglich wäre, eh man sich dann da ranntraut, und ob man das überhaupt schafft, wenn man keinerlei erfahrung mit dem verschlüsseln hat...

Gausi - Mi 12.12.07 11:11

---

Ich denke nicht, dass das so ohne weiteres möglich ist. AES ist ja nun doch ein recht verbreiter Algorithmus, und wenn der durch eine einfache Known-Plaintext-Attacke in sich zusammenfällt, wäre der bestimmt ganz schnell weg vom Fenster. :nixweiss:

Allesquarks - Mi 12.12.07 14:52

---

Hm AES gilt nicht umsonst als "sicher". Weißt du denn wenigstens die Schlüssellänge dann könntest du den Aufwand fürs Brute-forcen abschätzen. Ich schätze aber mal das es zeitlich weniger aufwändig wäre den Schlüssel über reverse Engeneering zu finden, denn irgendwo muss der ja stehen, sonst könnte er nicht benutzt werden.
Da ein Brute Force angriff wahrscheinlich mehrere Monate Jahre kA dauern würde ist da groß Spielraum.
Ein Tipp wäre vlt noch, dass der Schlüssel wahrscheinlich irgendwo im Adressraum des Prozesses im klartext liegen wird. Das würde dann bei Meemory ALignment die mögliche Anzahl der Schlüssel von 2^Schlüssellänge auf size(Adressraum)[byte]/4 runterkochen. Was vlt noch zu bewältigen wäre.

bensch - Mi 12.12.07 16:18

---

hi

nein, ich kenne die länge des schlüssels leider nicht. aber wenn ich in so einer verschlüsselten datei rumpfusche (ein paar zeichen entferne) kommt die meldung: "Base64: Incorrect String Format." aber das hat gleube ich nix mit der schlüssellänge zu tun...

Allesquarks hat folgendes geschrieben:

Ein Tipp wäre vlt noch, dass der Schlüssel wahrscheinlich irgendwo im Adressraum des Prozesses im klartext liegen wird. Das würde dann bei Meemory ALignment die mögliche Anzahl der Schlüssel von 2^Schlüssellänge auf size(Adressraum)[byte]/4 runterkochen. Was vlt noch zu bewältigen wäre.

das heißt ich muss herausfinden, welchen adressbereich die anwendung zur verfügung bekommen hat, und muss dann den ram durchsuchen? aber was muss ich da suchen?

Tilman - Mi 12.12.07 17:05

---

Zitat Wikipedia:

Zitat:

Entschlüsselung Bei der Entschlüsselung von Daten wird genau rückwärts vorgegangen. Die Daten werden zunächst wieder in zweidimensionale Tabellen gelesen und die Rundenschlüssel generiert. Allerdings wird nun mit der Schlussrunde angefangen und alle Funktionen in jeder Runde in der umgekehrten Reihenfolge aufgerufen. Durch die vielen XOR-Verknüpfungen unterscheiden sich die meisten Funktionen zum Entschlüsseln nicht von denen zum Verschlüsseln. Jedoch muss eine andere S-Box genutzt werden (die sich aus der original S-Box berechnen lässt) und die Zeilenverschiebungen erfolgen in die andere Richtung.

Demnach handelt es sich nicht um ein verfahren mit öffentlichem und Privatem Schlüssel wie RSA, sprich es müsste Theoretisch möglich sein aus Klartext und Chiffré den Schlüssel zu bestimmen denke ich. Einfach ist's aber sicher nicht.

Chryzler - Mi 12.12.07 17:52

---

bensch hat folgendes geschrieben:

aber wenn ich in so einer verschlüsselten datei rumpfusche (ein paar zeichen entferne) kommt die meldung: "Base64: Incorrect String Format." aber das hat gleube ich nix mit der schlüssellänge zu tun...

Also weißt du, dass die Datei nach der Verschlüsselung mit Base64 codiert wurde.

bensch hat folgendes geschrieben:

das heißt ich muss herausfinden, welchen adressbereich die anwendung zur verfügung bekommen hat, und muss dann den ram durchsuchen? aber was muss ich da suchen?

Er meint halt Reverse Engineering. Aber da das ja sicherlich bei dem Programm verboten ist...

bensch - Mi 12.12.07 18:51

---

Chryzler hat folgendes geschrieben:

Er meint halt Reverse Engineering. Aber da das ja sicherlich bei dem Programm verboten ist...

naja, verboten ist ein bisschen hochgegriffen. das tool ist freeware und niemand hat bei der veröffentlichung verboten, daran rum zu experimentieren :)

aber da ich von reverse engineering keine ahnung hab (kann leider nur in eine richtung programmieren ^^), wird das wohl nix mit dem key :(

aber danke für die antworten

Allesquarks - Mi 12.12.07 19:48

---

Ich meinte zweierlei. Vlt ist der Schlüssel in der exe oder einem anderen Teil versteckt. evt sogar im Klartext. Falls in dieser sogar noch verschlüsselt hilft es vlt das Programm mit einem Debugger durchzugehen und sich speziell die verschlüsselung anschauen, da ja dort der Schlüssel dann irgendwo entziffert werden muss.

Falls man das nicht kann/möchte sondern brute forcen möchte kann man noch hoffen, dass der Schlüssel im Ram/Adressraum unverschlüsselt vorliegt. Dann kann man einfach alle möglichen Schlüssel, die sich aus dem Ram ergeben durchprobieren, was die Anzahl der Möglichkeiten doch erheblich reduziert. Nötige Tools: Hexeditor.

bensch - Mi 12.12.07 20:57

---

Allesquarks hat folgendes geschrieben:

Ich meinte zweierlei. Vlt ist der Schlüssel in der exe oder einem anderen Teil versteckt. evt sogar im Klartext. Falls in dieser sogar noch verschlüsselt hilft es vlt das Programm mit einem Debugger durchzugehen und sich speziell die verschlüsselung anschauen, da ja dort der Schlüssel dann irgendwo entziffert werden muss.

das programm wurde durch einen obfuscator gejagt, ich hab vorher schonmal versucht, irgendwelche infos rauszubekommen. auch winspy scheitert daran, da bei der entwicklung des tools keine TWinControl - objekte (TButton, TListbox, TTreeview, etc.) benutzt wurden, sondern Objekte vom Typ TControl...
die entwickler haben also alle karten gezückt, um niemanden an den code kommen zu lassen...

Allesquarks hat folgendes geschrieben:

Falls man das nicht kann/möchte sondern brute forcen möchte kann man noch hoffen, dass der Schlüssel im Ram/Adressraum unverschlüsselt vorliegt. Dann kann man einfach alle möglichen Schlüssel, die sich aus dem Ram ergeben durchprobieren, was die Anzahl der Möglichkeiten doch erheblich reduziert. Nötige Tools: Hexeditor.

wie kann ich den Adressraum des progs durchsuchen? bzw. für was muss ich nen hex-editor benutzen? hab damit noch keine erfahrung. außer mit nem hex-editor, da hab ich früher mal dateien mit bearbeitet, das war aber nichts großartiges...

Allesquarks - Mi 12.12.07 23:19

---

Egal durch was das Programm unkenntlich gemacht wurde seinen Quellcode muss es noch enthalten. Hab das noch nie gemacht und da fragst du besser einen Debugging/Hacking/Cracking-Experten aber zum schreiben der Dateien wird ne Windows-Funktion verwendet werden. Dadurch wird das Programm prinzipiell im Betrieb unterbrochen und unter anderem der Instruktionpointer also die derzeitige Stelle im Programm gesichert. Und an die Information sollte man rankommen. Jedenfalls geht das ich weiß nur nicht wie.
Natürlich wäre es besser direkt in der Verschlüsselungsroutine anzuhalten aber da frag die Experten.

Zum Hex-Editor. Da braucht man glaube ich nur readprocessmemory (falls du ein Programm dafür schreibst), was viele Hexeditoren unterstützen. Noch besser wäre es nur die Stellen zu untersuchen, die sich bei Programmausfürhung ändern, denn die wenigsten Programme benutzen den gesamten zur Verfügung gestellten Speicher.

Das ganze fußt natürlich auf der Annahme, dass der key da überhaupt abgelegt wird. Wenn die den danach direkt wieder überschreiben wirst du um ein "debuggen" nicht herumkommen.

hazard999 - Do 13.12.07 12:23

---

probiers mal mit dem ida.

die entrypoints für die winapi-calls sollten klartext lesbar sein.

sollte etwas weiterhelfen.

r u

René

BenBE - Sa 22.12.07 20:48

---

Dein Vorhaben ist nicht ohne Aufwand möglich. Außerdem setzt man AES normalerweise dazu ein, dass man den Schlüssel brauch, um an die Daten zu kommen; sonst könnte man es auch lassen.

Aber nunja; hier mal ein kleiner Hinweis für dich: http://events.ccc.de/congress/2007/Fahrplan/events/2324.de.html

uall@ogc - Mo 07.01.08 15:40

---

Bist du dir überhaupt sicher, dass die Daten mit AES verschlüsselt werden und nicht nur im mit Base64 gespeichert werden?
Wenn du nur das Programm nachbauen willst, welches die Datei verschlüsselst, dann muss in diesem Programm der Schlüssel enthalten sein. Diesen kannst du durch Debuggen mehr oder weniger einfach herrausbekommen.
Um welches Programm handelt es sich denn?

bensch - Mi 09.01.08 14:05

---

hi

der thread hat sich auch erledigt. der entwickler, bzw. andere entwickler haben den aes-key veröffentlicht.

thx für eure antworten!