Hallo ich habe das Password eines rar Archives vergessen. Jedoch kann ich es relativ gut eingrenzen es ist eine kombination von etwa 15 möglichen Wörtern (insgesamt 3 oder 4 davon), maximal 2 Buchstaben im gesamten Password sind großBuchstaben, maximal 2 Buhcstaben sind L33T (verwende nur 3 L33T Paare) und eine anschließende maximal 5 stellige Kombination von Zahlen und Sonderzeichen (ausschließlich *-+). Das gesamte Passwort hat etwa 28 Stellen. wenn ich eine Passwortliste erstellen könnte mit genau diesen Vorgaben, wäre es durchaus machbar. Wenn ich aber bei den mir bekannten Programmen eine Passwortliste mit den 15 genannten Wörtern erstelle, jede der 28 Stellen klein- und groß geschrieben wird, alles gel33tet wird usw, dauert der Prozess Monate wenn nicht Jahre Also die Frage ist, gibt es Programme mit denen ich eine Passwortliste mit diesen Vorgaben erzeugen kann?
Robert E. schrieb: > Also die Frage ist, gibt es Programme mit denen ich eine Passwortliste > mit diesen Vorgaben erzeugen kann? Lies c't 13 vom 6.6., Seite 162: Hacker-Angriff gegen mich selbst. Da wird ziemlich genau das beschrieben. Georg
Robert E. schrieb: > Wenn ich aber bei den mir bekannten Programmen > eine Passwortliste mit den 15 genannten Wörtern erstelle, jede der 28 > Stellen klein- und groß geschrieben wird, alles gel33tet wird usw, > dauert der Prozess Monate wenn nicht Jahre Wenn du schon Monate brauchst um die Liste zu erstellen, dann wird das durch Probieren der Liste mindestens genau so lange brauchen. :D Spontan fallen mir Hashcat oder "John the ripper" ein. Beide lassen sich parametrieren, auch was den Passwort Suchraum angeht. Details musst du selbst googlen.
Robert E. schrieb: > wenn ich eine Passwortliste erstellen könnte mit genau diesen Vorgaben, > wäre es durchaus machbar. > .... > Also die Frage ist, gibt es Programme mit denen ich eine Passwortliste > mit diesen Vorgaben erzeugen kann? Ich hatte mal ein vergleichbares Problem wie deines bei einer Truecrypt Containerdatei bei der ich das Passwort vergessen hatte. Die bekannten Programme habe ich nicht genutzt, da ich wusste, dass ich mir das Passwort aus einem Algorithmus definiert habe. Allerdings wusste ich die Parameter nicht mehr genau und beim Algorithmus war ich mir nicht sicher, ob ich den einen Weg oder den anderen Weg gegangen bin. Also habe ich mir ein C Programm geschrieben das anhand dem Algorithmus mit verschiedener Parametrisierung alle Kombinationen einfach durchging und an die Truecrypt EXE Datei das Passwort via system() Aufruf zum gleich testen übergab. Damit konnte ich mein Passwort wieder berechnen und auch finden. Beim korrekten Passwort brach das Programm ab und gab das Passwort an der Konsole aus. Das ganze hat auf einem Athlon TB vielleicht ca. 5 min gedauert um das Passwort zu finden. > Wenn ich aber bei den mir bekannten Programmen > eine Passwortliste mit den 15 genannten Wörtern erstelle, jede der 28 > Stellen klein- und groß geschrieben wird, alles gel33tet wird usw, > dauert der Prozess Monate wenn nicht Jahre Wenn ich dich richtig verstanden habe, dann besteht dein PW aus 3 Wörtern aus einem Worterbuch von 15 Wörtern. Sagen wir mal "Haus", "Baum", "Esel" Eine Kombination könnte also sein: hauseselbaum 2 Buchstaben sind Großbuchstaben, also bspw so: hauSeselbaUm maximal 2 Buchstaben sind L33T Sprech, also: hauS3s3lbaUm und am Ende gibt's ne fünf stellige Kombination von Zahlen und Sonderzeichen (ausschließlich *-+). Also bswp. hauS3s3lbaUm67*3+ Habe ich dich hier richtig verstanden? Die Fünfstellige Kombination am Ende lässt sich einfach generieren. Cache ist schneller als RAM. Eine Liste in eine Datei zu schreiben kannst du ganz vergessen, denn SSDs und Festplatten sind noch langsamer. Es kann also Sinn machen die Kombination in einer innersten Programmschleife jedes mal neu zu erzeugen und dann dem vorherigen Wörterstring einfach dranzuhängen und das Ergebnis dann zu testen. Bei 10 Ziffern und 3 Sonderzeichen und einer Länge von 5 sind das nur 13^5 Kombinationen für dieses Teilstück. Die musst du dann für jeden zuvor generierten Wörterstring dann durchprobieren. Bei dem Wörterstring lässt sich der Aufwand eingrenzen, sofern das nur Buchstaben und Zeichen aus dem ASCII Zeichensatz sind. Wenn die Wörter auch Umlaute enthalten sollten, musst du die halt gesondert dazu nehmen. Die Wörter gehören jeweils in einen eigenen String, dann kannst du die Strings aneinanderketten. Beim L33T Sprech könntest du dir überlegen, ob du die Suche noch weiter eingrenzen kannst. Vielleicht hast du nur e in 3 umgewandelt, dann kannst du andere L33T Zeichen ignorieren und somit die Suche noch weiter eingrenzen. Falls die Wörter, wie im obigen Beispiel, alle klein geschrieben werden, fängst du mit kleingeschriebenen Wörtern an und Kombinierst 3 Wörter aus den 15. Dann änderst du zwei Kleinbuchstaben in Großbuchstaben und 2 Buchstaben in L33T Sprech. Am Schluss hängst du den Zahlencode in einem Schleifendurchlauf hinten dran. Wenn nichts gefunden wurde, gehst du in die vorherige Schleife zurück, und änderst dort nochmal den L33T Sprech. Eine Schleife davor entsprechend dann die Großbuchstaben. Im Prinzip kannst du die Anzahl der möglichen Kombinationen ausrechnen, dass wäre das erste was du tun solltest, dann kannst du auch ungefähr einschätzen wie lange es dauert. Ich mach das jetzt aber nicht für dich, da es momentan recht spät ist. Siehe dazu das Mathekapitel Kombinatorik. https://de.wikipedia.org/wiki/Kombination_(Kombinatorik) Stell dazu am besten die Formel auf und rechne es dann aus. Beachte auch, dass die Wörter ohne Wiederholung sind. 3 Wörter aus einem Wortschatz von 15 gibt mit Wiederholung 15^3 Möglichkeiten. Ohne Wiederholung siehe oben der Link, also noch weniger und somit sehr überschaubar. Die Kombinationen für Großbuchstaben und L33T Sprech, sowie der Reststring am Ende kommen noch dazu. Wenn du dann deinen eigenen Code schreibst, dann mach keine Listen, sondern berechne das direkt und teste es gleich auf der CPU bzw. füre es im Cache aus. Die Aufgabe ist durchaus parallelisiberbar, also verteile es auf alle deine Kerne. Meine Lösung war Quick & Dirty, da ich das bestehende truecrpyt Programm immer einfach aufgerufen habe. Das kostet Zeit, da der Prozess erzeugt und beendet werden muss und der Kernel entsprechend zwischen den Prozessen switchen muss. Schneller ginge es über API Aufrufe ohne Umweg über den Aufruf externe Kommandozeilenprogramme. Eventuell gibt's ne API die das in RAR verwendete Verschlüsselungsverfahren durchführen kann. Die Passwortcrackprogramme werden darauf natürlich spezialisiert sein, mit denen geht das alles, wenn du sie richtig Parametrisieren kannst und das genug einschränken kannst, schneller. Hilfreich wäre übrigens auch, wenn du dich daran erinnern könntest, ob die Zahlenkombination mit einer großen oder kleinen Ziffer anfing. Wenn du bspw. weiß, dass die erste Ziffer nicht größer als sagen wir mal eine 4 war, dann kannst du alle Kombination => 5XXXX schon einmal ausschließen. Wenn du weißt, dass die erste Ziffer nicht kleiner als sagen wir mal eine 3 war, dann kannst du auch da alle Kombinationen < 3XXXX ausschließen. Grundsätzlich macht es immer Sinn, sich ausgiebig Gedanken darüber zu machen, wo man das PW noch weiter eingrenzen kann. Wenn du bspw. weiß, dass das PW mit einem Buchstaben begann, der nach sagen wir mal m im Alphabet kommt, kannst du alle Kombinationen die mit Wörtern mit Bu8chstaben <= m anfangen, ebenfalls auschließen. Wenn das getan ist, dann stell die Formel auf und rechne aus, wieviele mögliche Kombinationen es überhaupt geben kann. Anhand dieser Anzahl und einem kleinen Benchmarktest, der zeigt, wieviele Kombinationen du bspw, in 10 s mit der CPU durchtesten kannst, kannst du dann auch einschätzen, wie lange das im Worst Case Fall dauert. Mit etwas glück, wird das PW lange vor dem Worst Case Fall gefunden.
dafür gibt es sogenannte Wordlist-generatoren..(https://github.com/topics/wordlist-generator) die können aus listen generieren, case wechseln, 1337 implementieren etc. sowas zusammen mit elcomsofts archpr und schon kanns losgehen, dauert dennoch unfassbar lange.. aber manchmal ist "dauert lange" eben besser als "ist nicht zu machen" ;) welcher generator für dich der richtige ist musst Du selber entscheiden, aber sicherlich ist einer dabei der Dir den grössten teil der Arbeit abnehmen kann. 'sid
uups vergessen: ich schlage aus der Liste da oben Mentalist vor: https://github.com/sc0tfree/mentalist ich hab damit recht gute Erfolge erzielt gehabt jdf. 'sid
sid schrieb: > sowas zusammen mit elcomsofts archpr Was ist denn der Vorteil von dieser Software gegenüber dem Opensource tools Hashcat oder John the ripper ? oder anders gefragt warum sollte ich dafür 49 oder 99 euro zahlen wen ich die anderen in mein Blackarch für umme bekomme?
imonbln schrieb: > Was ist denn der Vorteil von dieser Software gegenüber dem Opensource > tools > Hashcat oder John the ripper? keiner wirklich ausser Bequemlichkeit. bei jtr wusste ich nichtmal dass man den auf archive ansetzen kann um ehrlich zu sein. hashcat hatte ich mal Probleme beim neustart mit (hat die session nicht genommen...) das war minimal lästig (ging da aber nicht um archivpasswort sondern n ios backup... egal) in meinem Satz da oben fehlt ein "zB" .. 'sid
sid schrieb: > dafür gibt es sogenannte > Wordlist-generatoren.. Sobald RAM-Zugriffe ins Spiel kommen wird's langsam. Die PW in der CPU generieren, dann prüfen und wegwerfen und gucken das alles was Speicherplatz braucht, inkl. dem Code für die Prüfung des generierten PW, in den Cache passt ist viel schneller. Die Wordlistgeneratoren werden die generierten PW ganz sicher im RAM zwischenspeichern und dann auch irgendwann auf den Datenträger schreiben.
Nano schrieb: > Sobald RAM-Zugriffe ins Spiel kommen wird's langsam. > > Die PW in der CPU generieren, dann prüfen und wegwerfen und gucken das > alles was Speicherplatz braucht, inkl. dem Code für die Prüfung des > generierten PW, in den Cache passt ist viel schneller. > > Die Wordlistgeneratoren werden die generierten PW ganz sicher im RAM > zwischenspeichern und dann auch irgendwann auf den Datenträger > schreiben. Ich bin mir nicht sicher ob beim Problem des TE eine frühzeitige Optimierung was bringt. Die Regeln nach denen er sein Passwort erstellt hat sorgen ja dafür dass "nur noch" eine relativ kleine Wordlist übrig bleibt. Da sollte der RAM-Zugriff kein Problem sein, wahrscheinlich nicht mal das HDD-IO. Irgendwann muss ja schließlich auch mal unrar oder was-was-auch-immer aufgerufen werden um das PW zu testen. Wenn ja bei jedem Versuch ein neuer Prozess gespawnt wird wirds eh schon "teuer".
Nano schrieb: > Sobald RAM-Zugriffe ins Spiel kommen wird's langsam. rar zu knacken alleine ist so unglaublich langsam, dass das absolut keine Rolle spielt. Wordlisten haben mMn immense vorteile ggü der on-the-fly Generierung, man kann sie nämlich schön partitionieren und parallel auf mehreren Rechnern rechnen lassen, das wird schon schwierig wenn man dasselbe mit der on-the-fly methode versucht. Aber selbst auf nur einem Rechner hab ich lieber ne Liste und weiss das selbst wenn das pause/resume fehlschlägt (wie mir passiert) dass ich nur die ersten 32000 Zeilen der Liste entfernen muss um einigermassen wieder da bin wo ich pausiert hatte. (man ist ja eh neugierig und guckt immer wieder nach wo er grad ist ;)) 'sid
moep schrieb: > https://www.heise.de/ct Hab ich oben auch schon vorgeschlagen (ist sehr fundiert), aber entweder ist das dem TO zu mühsam selbst zu lesen oder er hat überhaupt das Interesse verloren. Oder das Passwort ist ihm wieder eingefallen. Georg
Robert E. schrieb: > wenn ich eine Passwortliste erstellen könnte mit genau diesen Vorgaben, > wäre es durchaus machbar. Sicher? Wie viele Variationen erwartest du denn ungefähr? Oliver
Le X. schrieb: > Nano schrieb: >> Sobald RAM-Zugriffe ins Spiel kommen wird's langsam. >> >> Die PW in der CPU generieren, dann prüfen und wegwerfen und gucken das >> alles was Speicherplatz braucht, inkl. dem Code für die Prüfung des >> generierten PW, in den Cache passt ist viel schneller. >> >> Die Wordlistgeneratoren werden die generierten PW ganz sicher im RAM >> zwischenspeichern und dann auch irgendwann auf den Datenträger >> schreiben. > > Ich bin mir nicht sicher ob beim Problem des TE eine frühzeitige > Optimierung was bringt. > Die Regeln nach denen er sein Passwort erstellt hat sorgen ja dafür dass > "nur noch" eine relativ kleine Wordlist übrig bleibt. Da sollte der > RAM-Zugriff kein Problem sein, wahrscheinlich nicht mal das HDD-IO. Es kommt auf die Anzahl der Kombinationen an. Bei sehr vielen addieren sich die ms die man im RAM verschwendet zu einer ordentlichen Dauer. Deswegen mein Vorschlag allein im Cache zu bleiben. > Irgendwann muss ja schließlich auch mal unrar oder was-was-auch-immer > aufgerufen werden um das PW zu testen. Nicht unbedingt. Ich weiß jetzt nicht, wie genau die RAR Dateien gesichert werden, aber ich könnte mir vorstellen, dass ein asymmetrisches Verschlüsselungsverfahren einen Schlüssel für ein symmetrischen Verschlüsselungsverfahren in der RAR Datei sichert und nur der symmetrische Schlüssel auf die gesamte RAR Datei angewendet wird, während dieser dann durch das asymmetrische Verfahren gesichert ist und für letzteres ist dann das PW notwendig. Wenn dem so ist, würde es genügen, den verschlüsselten symmetrischen Schlüssel aus der RAR Datei in verschlüsselter Form zu extrahieren und dann das generierte PW mit dem asymmetrischen Verfahren auf diesen anzuwenden. > Wenn ja bei jedem Versuch ein neuer Prozess gespawnt wird wirds eh schon > "teuer". Das ist richtig. Wenn es irgendwie möglich ist, sollte man das daher bei einer zu großen Zahl an möglichen Kombinationen vermeiden.
sid schrieb: > Nano schrieb: >> Sobald RAM-Zugriffe ins Spiel kommen wird's langsam. > > rar zu knacken alleine ist so unglaublich langsam, > dass das absolut keine Rolle spielt. Es summiert sich in der Summe auf. > Wordlisten haben mMn immense vorteile ggü der on-the-fly Generierung, > man kann sie nämlich schön partitionieren und parallel auf mehreren > Rechnern rechnen lassen, Das geht mit on the fly Generatoren genauso. Du musst halt Start und Stop Bedingungen für die on the fly Generatoren richtig einstellen und dann den einzelnen Kernen und Prozessoren zuweisen. > Aber selbst auf nur einem Rechner hab ich lieber ne Liste und weiss > das selbst wenn das pause/resume fehlschlägt (wie mir passiert) > dass ich nur die ersten 32000 Zeilen der Liste entfernen muss um > einigermassen wieder da bin wo ich pausiert hatte. On the fly kann den letzten Schlüssel genauso ausgeben und da wieder weitermachen, wo es aufgehört hat. > (man ist ja eh neugierig und guckt immer wieder nach wo er grad ist ;)) Ja, da könnte man sich alle 1000 PW auch mal ein PW oder die Parameter für die Schleifen ausgeben lassen, dann weiß man auch wo man ist. Ich habe das bei meinem Code damals so gemacht.
Nano schrieb: > Es summiert sich in der Summe auf. was summiert sich denn da auf? das rar passwort aktueller Versionen kann soweit ich weiss NUR von der unrar überprüft werden (weil es keinen passwort hash gibt den man extrahieren könnte, sondern nur den hash der "unkomprimierten" dateien; solange die unrar braucht zu entpacken und den hash zu prüfen hat 'was auch immer tool' laaange genug zeit n film zu gucken, radio zu hören, kaffee zu kochen und nebenbei ne wordlist zu laden ... geschätzt sind je nach dateigrösse 5-10 p/s realistisch. Deswegen muss man soweit ich mich erinnere den Dateinamen eines file im Archiv an hascat übergeben (um nur jene -hoffentlich kleine- Datei zu prüfen statt aller enthaltenen Dateien) mit bekanntem pw hash gäbe ich Dir recht das wären aber auch 20k mal mehr passworte in der sekunde die man überprüfen könnte passwort hashes in rar archiven gibt es aber meines Wissens nach seit rar2.x nichtmehr; gestehe allerdings, dass ich mich um Derartiges nur sehr sporadisch kümmere ;) 'sid
sid schrieb: > mit bekanntem pw hash gäbe ich Dir recht das wären aber auch 20k mal > mehr passworte in der sekunde die man überprüfen könnte > passwort hashes in rar archiven gibt es aber meines Wissens nach seit > rar2.x nichtmehr; > gestehe allerdings, dass ich mich um Derartiges nur sehr sporadisch > kümmere ;) Zumindest hat das Projekt JohnTheRipper ein rar2john.c (https://github.com/magnumripper/JohnTheRipper/blob/bleeding-jumbo/src/rar2john.c) welches angeblich den Hash aus ein rar3 und rar5 bekommen kann. von daher ist schon wahrscheinlich dass man nur den Hash probieren muss und nicht immer unrar auf verdacht starten muss.
Robert E. schrieb: > maximal 2 Buchstaben im gesamten Password sind großBuchstaben, > maximal 2 Buhcstaben sind L33T Vielleicht wäre ein erster Ansatz, deine vermuteten Passwörter fehlerfrei einzutippen, damit scheinst du ein Problem zu haben. Ansonsten habe ich deine Beschreibung nicht vollständig verstanden, aber nach dem was ich meine, verstanden zu haben, gibt es mindestens 1.4*10^14 Möglichkeiten. Viel Spaß!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.