[gelöst]Wörterbuch mit Zahlen erstellen

[Conax]

Wie man bestehende Wörterbücher sehr effektiv bearbeiten kann weiss ich ja nun. Mich würde jetzt mal interessieren kann man sich so ein brute force Wörterbuch mit Zahlen (bei Buchstaben + Sonderzeichen kann man das vergessen) auch mit ein paar Befehlen automatisch erstellen lassen?

Also von 0 bis 9 wobei auch solche Zahlenkombinationen wie "0000000" oder "0000001" enhalten sind. Ich denke so einstellig bis zehnstellig dürfte da von der Rechenpower her hinkommen.

 

[Anonymous]

Mich würde jetzt mal interessieren kann man sich so ein brute force Wörterbuch mit Zahlen (bei Buchstaben + Sonderzeichen kann man das vergessen) auch mit ein paar Befehlen automatisch erstellen lassen?

Alles kein Problem.

reine Wörter: Ein riesiges Buch oder irgend einen riesigen Text, oder gleich das halbe Internet runterladen. Dieses je nach Format zuerst einmal in txt umwandeln. Dabei Sonderzeichen entfernen. Danach awk drüber jagen und schon ist das Wörterbuch fertig. Am besten man nimmt dazu gleich ein Buch oder Artikel in dem es um die 10000 meist benutzen Passwörter geht Große Namenslisten, Telefonbücher oder ähnliches ist auch gut, man muss nur vorher die Zahlenfelder und Sonderzeichen entfernen,

 awk '{for (i=1;i<=NF;i++) x[$i]++};END{for (i in x) print i}' text.txt > worterbuch

reine Zahlen vollmathematisch, sollte man aber etwas umsortieren, (umsortieren geht zB auch mit dem awk Befehl von oben)

for i in $(seq -w 0 100000); do echo $i; done > worterbuch

Buchstaben, Zahlen, Sonderzeichen, nach bestimmten Mustern und mit voreingestellen Stepwerten

for i in {1,0,2,3}{1,2,4,5,9}{A,B,C,D,E}{1,0,6,8}{1,0,2,3}{1,2,4,5,9,a,b,c,d,e}; do echo $i; done | awk '{for (i=1;i<=NF;i++)x[$i]++};END{for (i in x) print i}' > worterbuch

Fertige oder halbfertige Wörterbücher kann man auch noch weiter über awk oder sed und ähnlichen Befehlen weiter bearbeiten oder ändern, selektiv vergrößern, verkleinern oder was auch immer.

Man muss nur ein paar Befehle beherrschen und wissen was man überhaupt will. All zu tiefgreifend wollen wir das hier nicht ausschöpfen, wenn es um spezielle Befehle, Tricks oder Techniken mit Konsolbefehlen geht, können wir gerne helfen, aber das Erstellen eines "totsicheren" Wörterbuchs mit dem mit hoher Wahrscheinlichkeit in ein paar Stunden sehr viele schwache Passwörter geknackt werden könnten, werden wir hier natürlich nicht vorstellen.

robi

 

[/dev/null]

Einen wunderschönen guten Morgen ....

Schönes Gedankenspiel.
Zwei Sätze finde ich ganz besonders gelungen:

Ein riesiges Buch oder irgend einen riesigen Text, oder gleich das halbe Internet runterladen.

und

eines "totsicheren" Wörterbuchs mit dem mit hoher Wahrscheinlichkeit in ein paar Stunden sehr viele schwache Passwörter geknackt werden könnten

(FETT-Markierung von mir.)


@Conax:
Du hast in deiner Ausgangsfrage ja das Wort "brute force" erwähnt.
Aber ich vermute, dass du da etwas durcheinander haust.
Jedes (nennenswerte) "Passwortknackprogramm" benutzt zwei Techniken:
1.) Den Wörterbuchangriff, und
2.) den brute force-Angriff
Sehr gute Programme verknüpfen auch noch beide Techniken, indem sie im Wörterbuch noch bestimmte übliche Austauschfunktionen (a=> @ usw.), Drehungen, Spielereien mit der Großschreibung usw. anwenden oder noch irgendwo (meist am Ende, weil ONU das so macht) eine Zahl einfügen.

Beim Wörterbuchangriff werden Listen durch die Nutzer "häufig und gern" verwendeter Passwörter verwendet. Also sinnvolle Wörter aus Namen, Städten, Begriffen usw. Also alles das, was sich ONU einfach merken und ohne viel Fantasie als PW verwenden kann.
Vorteil: Dank ONU eine sehr hohe Trefferquote. Und sehr schnell, da diese Listen zwar riesengroß aber im Vergleich zur zweiten Methode doch winzig klein sind.

Beim echten brute force-Angriff generiert das Programm selbst aus einem vorgegebenen Zeichenvorrat und Größe des Passwortes, bzw. aus dynamisch wachsendem Zeichenvorrat und bei Misserfolg immer größer werdenden Anzahl von Zeichen die Passwörter und wenden sie an. => Das kann ein Programm viel besser und viel schneller als du!

Es ist also völlig sinnfrei, Passwortlisten mit "Zufall" zu füllen.

BTW:
1.) Ich checke Passwörter auch auf Anfälligkeit gegenüber reinen Wörterbuchangriffen. Der Gockel hat mir geholfen ... . Selbst in der Standardinstallation von openSUSE ist eine derartige Bibliothek vorhanden, welche anzeigt, ob ein PW genutzt werden sollte oder lieber nicht.
2.) In der Literatur gibt es viele Rechenbeispiele für die Zeitdauer des Brechens guter Passwörter per brute force-Angriff. Da ich mal davon ausgehe, dass du dir weder ein Rack mit ein paar Hundert High-end-Grafikkarten hinstellen willst, oder dir gar Rechenleistung in der Cloud oder die wirklich guten Rainbow Tables kaufst, wünsche ich dir viel Spaß und auch Ausdauer bei deinem neuen Hobby.

MfG Peter

 

[abgdf]

Ich weiß auch nicht so recht, was Du meinst:

Also von 0 bis 9 wobei auch solche Zahlenkombinationen wie "0000000" oder "0000001" enhalten sind. Ich denke so einstellig bis zehnstellig dürfte da von der Rechenpower her hinkommen.

So ein Programm dürfte eigentlich nicht schneller werden, wenn es eine gespeicherte Liste mit Zahlen durchgeht, als wenn es die Zahlen gleich selbst generiert (und gar nicht erst die Liste einlesen muß).

Mich würde jetzt mal interessieren kann man sich so ein brute force Wörterbuch mit Zahlen (bei Buchstaben + Sonderzeichen kann man das vergessen) auch mit ein paar Befehlen automatisch erstellen lassen?

Warum soll man das "bei Buchstaben + Sonderzeichen ... vergessen" können? Man kann doch Zahlen in Buchstaben und Sonderzeichen umwandeln, z.B. mit dem ASCII-Code oder mit Unicode.

Sehr merkwürdig das alles.

 

[Conax]

Nein ich glaube einige haben mich hier miss verstanden. ich verdeutliche das Beispiel mit den Zahlen mal etwas. Bei WPA2 z.B. besteht die Passwortlänge mindestens aus 8 Zeichen also von 00000000 bis 99999999. Besteht das Passwort also nur aus Zahlen und ist 8 Zeichen lange gäbe es also 1.0000.0000 mögliche Passwörter.

Mit ner Grafikkarte und pyrit dürfte das locker in ner Stunde dann durch sein. Bei einer stelle Mehr eben 10 Stunden und bei noch einer mehr eben 100 Stunden - also schon ein paar Tage. Deswegen finde ich das bei Zahlen es maximal bis zu 10 Stellen sinnvoll ist. Die Warscheinlichkeit das man damit ein wpa2 passwort knackt liegt vielleicht bei 2% aber immerhin. Nun könnte man dann ja mit dieser riesigen Zahlenliste rainbow tables erstellen für die häufigsten essids wie "Fritz Box ...", "easybox" oder "d-link ..." dann geht das ganze noch wesentlich schneller. Mit dieser Art der Rainbow tables habe ich dann vielleicht nur noch eine 0,5% ige chance da ja die ohne standard essid schon mal wegfallen aber es geht mir ja auch nicht darum tatsächlich in fremde Netze einzusteigen - mach das ja nur für mich zum Spaß. Es gibt sicherlich Programme wie john the ripper oder ähnlich die einen bruteforce angriff mit zahlen machen nur um eine rainbow table zur erstellen brauche ich meines wissens nach dafür eine txt datei also ein wörterbuch mit zahlen. Nur wenn ich schon eine txt datei erstelle mit sämtlichen zahlen bis zur stelle 10 möchte ich eben auch die unter acht stellen also siebenstellige, sechsstellige etc. mit drin haben denn die kann man ja evtl mal für was anderes auch verwenden (man muss das ja nicht alles doppelt und dreifach machen).

Eine Liste mit zahlen kann ja eigentlich nicht schaden weil dann könnte man ja mehrere listen kombinieren. Also einmal das wörterbuch mit Begriffen wie Apfel und dann dahinter die liste mit Zahlen z.B. 111 und schon hätte man Apfel111. Also ich kenne bis jetzt nur so ein Programm von elcomsoft das sog. advanced dictionary attacks fährt also wo man nur ein Wörterbuch angibt und dann das Programm selbstständig die 111 oder 112 oder 113 generiert und dann einfach hinten dran setzt (gleiches gilt für jahreszahlen wie 1965 oder aus einem a ein @ macht oder aus einem E eine 3 ).

Bei der bruteforce geschichte mit zahlen und buchstaben (groß und klein) will ich nicht extra ne txt datei falls ich das wirklich mal ausprobieren möchte dann tuts ja auch john the ripper

Also zusammengefasst sehe ich das so:
Bruteforce attacks mit zahlen gehen für otto normal ohne probleme bis 10 Stellen (alles andere darüber wäre mir persönlich der aufwand nicht wert aber das ist wieder ein anderes Tehma)
Bruteforce attacks mit zahlen und Buchstaben gehen ohne probleme bis 6 Stellen (gut für Sicherheitsunternehmen und nem cluster voller grakas gehen vielleicht bis 9 Stellen)

und zum schluss bei den wörterbüchern je nach umfang des wörterbuchs und vor allem die gewünschten variationen die mit einfliesen sollen (siehe oben beispiele zu den advanced dictionary attacks) Sekunden bis .....

Also bei all den genannten Methoden denke ich das man vielleicht allerhöchstens 20% der Passwörter damit knackt (ist jetzt nicht allein auf wlan bezogen) und das dürfte wohl schon hoch gegriffen sein (mittlerweile hat sich ja doch rumgesprochen was ein sicheres passwort ausmacht).

Es gibt ja auch so "tolle Firmen" die sich auf diese Art spzialisiert haben und damit ihr Geld verdienen siehe: https://www.wpacracker.com/

"We now offer Germany dictionary support, a 284 million word extended English dictionary option, and ZIP file cracking"

Im netz gibts ja auch viele "dictionarys" teilweise mit millionen von einträgen aber die die ich bisher gesehen habe waren qualitativ nicht wirklich das gelbe vom Ei. Ich frage mich ob dieses 284 millionen wörter Wörterbuch der Firma qualitativ hochwertig ist oder ob man da auch eher auf das Konzept Masse statt Klasse gesetzt hat - ich mein für den potenziellen Kunden macht das natürlich erst einmal was her wenn der so ne Zahl präsentiert bekommt.

 

[abgdf]

Also, mich interessiert das Cracken von Passwörtern eigentlich nicht. Ich habe mir jedoch mal 'ne Funktion in Python (2.x) geschrieben, die mir Zahlen mit einer bestimmten Menge Nullen am Anfang zurückgibt. Die kann man nämlich brauchen, um z.B. Bilder zu img001.jpg, img002.jpg ... img999.jpg umzubenennen. Also, dieses Python-Skript sollte die Zahlen von 1 bis 10.000 mit Nullen für 1 Million davor ausgeben:

#!/usr/bin/env python
# coding: iso-8859-1

def zeropadded(a, nr = 10):

    if type(a) != int or a == 0:
        raise ValueError, "First Argument to function 'zeropadded()' must be a positive integer."

    if type(nr) != int or nr % 10:
        raise ValueError, "Second Argument to function 'zeropadded()' must be an integer, that can be divided by 10."

    b = []
    while not nr % 10:
        b.append(nr)
        nr /= 10
    x = 0
    for i in b:
        if a < i:
            x += 1
    return x * "0" + str(a)

for i in range(1, 10001, 1,):
    print zeropadded(i, 1000000)

Python ist natürlich nicht die allerschnellste Sprache für sowas. :roll:

HTH

 

[framp]

...Python ist natürlich nicht die allerschnellste Sprache für sowas. :roll:

Warum nutzt Du nicht die Format Funktion von Python und die C Implementierung ? Ist sicherlich schneller.

#!/usr/bin/env python 
#-*- coding: utf-8 -*-

for i in range(1, 10001, 1,):
    print "%07i" % (i)

 

[Anonymous]

@framp @abgdf
Ich frag mich was ihr gegen seq habt.

seq -w  0 1000000000 | head -15
0000000000
0000000001
0000000002
0000000003
0000000004
0000000005
0000000006
0000000007
0000000008
0000000009
0000000010
0000000011
0000000012
0000000013
0000000014

und warum man das in eine Datei schreiben muss, wenn es an jeder Stelle in einem Script bequem erzeugt werden kann, und somit bei Gebrauch mit den Variablen kombiniert werden kann.

robi

 

[framp]

@framp @abgdf
Ich frag mich was ihr gegen seq habt.

loool

 

[framp]

@robi: Ist nun seq oder

#include <stdio.h>

main() {
        unsigned i;
        for (i=0; i<=10000; i++) {
                printf("%07u\n",i);
        }
}

schneller :-D

 

[framp]

Antwort:

framp@obelix:/framp> time ./a.out > /dev/null

real    0m0.004s
user    0m0.003s
sys     0m0.001s
framp@obelix:/framp> time seq -w  0 10000 > /dev/null

real    0m0.013s
user    0m0.012s
sys     0m0.001s

:-D

 

[abgdf]

Ach so wird das gemacht. Haha, na, man lernt ja nie aus.

 

[Anonymous]

bei mir nicht du musst das kompilieren schon mit reinrechnen, sonst ist das ja unfair.

rob@linux:~> time ( gcc framp.c ; ./a.out > /dev/null )

real    0m0.313s
user    0m0.182s
sys     0m0.069s
rob@linux:~> time seq -w 0 10000 > /dev/null

real    0m0.071s
user    0m0.032s
sys     0m0.004s

Wenn du das innerhalb eines Scriptes erst noch kompileren willst, das sieht dann ungefähr so aus.
Erkläre das dann mal Otto-Normal-Linuxer was dort passiert :???:

#!/bin/bash
cat > framp.c << END
#include <stdio.h>
main() {
        unsigned i;
        for (i=${1:-"0"}; i<=${2:-"100000"}; i++) {
                printf("%07u\n",i);
        }
}
END
gcc -O3 -s -o a.out framp.c

for i in $(./a.out)
do
        echo $i
done
rm framp.c a.out

robi

 

[framp]

bei mir nicht du musst das kompilieren schon mit reinrechnen, sonst ist das ja unfair.

Da bin ich nicht ganz Deiner Meinung. seq liegt auch schon compiliert vor :roll:

Erkläre das dann mal Otto-Normal-Linuxer was dort passiert :???:

Nee ... das ist eine kleine Hausaufgabe die leicht zu erledigen zwischen Kaffee einschenken und -trinken ist

 

[abgdf]

Nur mal zum Verhältnis von C, der Shell und Skriptsprachen:
Also, C wurde ab 1971 unter anderem entwickelt, um die Unix-Shell-Befehle zu schreiben. Daher wurde seq also in C geschrieben. Es macht wenig Sinn, seq nochmal in C zu schreiben, wenn man nicht etwas Wesentliches daran verbessern möchte (und auch dann empfiehlt sich eher ein Patch).
Der C-Code von framp ist wahrscheinlich schneller als ein Aufruf von seq, weil seq noch die Befehlsargumente verarbeitet usw.. Wenn etwas ausgegeben werden soll, wird im Code von Shell-Befehlen üblicherweise dasselbe "printf()" oder "puts()" verwendet. framps Beispiel dürfte also schon fast maximale Geschwindigkeit haben, vielleicht könnte man noch mit der gcc-Option "-O2" oder "-O3" kompilieren.
Bei einem Geschwindigkeitstest kann man das Kompilieren nicht mitrechnen, sonst müßtes man seq ebenfalls erstmal mitkompilieren.
Es macht auch eigentlich wenig Sinn, C-Code in ein Shell-Skript einzubinden und diesen bei der Ausführung zu kompilieren. Man kompiliert ja auch nicht erst cat oder grep, wenn man damit ein Shell-Skript ausführst. Trotzdem interessantes Beispiel.
In einem Shell-Skript führt man typischerweise mehrere (in C implementierte) Shell-Befehle hintereinander aus. Hier wäre es also der gängige Weg, seq zu verwenden. Andererseits hindert einen aber auch niemand, einen eigenen Shell-Befehl in C zu schreiben. Man kann eigentlich nicht sagen, ob dies oder das die "bessere Lösung" wäre.
Python soll dagegen plattformübergreifend laufen. Deshalb verwendet man dort eher eigene Implementationen und vermeidet es, externe Shell-Befehle aufzurufen. So gibt es anstatt "rm" "os.remove()", statt "mv" "shutil.move()".
Ein externer Aufruf von "seq" wäre dort also unüblich. Meine Funktion kann man bestimmt leichter mit Formatstrings schreiben. Andererseits sind die in Python sozusagen ein Erbstück von Cs "printf()". Das heißt, sie sind nicht so leicht lesbar, und deshalb ist es vertretbar, sie in Python eher weniger zu verwenden.
Dies ist das Konsole-Forum, und Conax möchte wohl am liebsten Shell-Befehle verwenden. Da bietet sich dann also seq an. Das bedeutet aber nicht, daß die anderen Lösungsansätze völlig verfehlt wären. Da gefällt mir die Toleranz, die bei Perl sogar zum Motto geworden ist: "There's more than one way to do it."

Gruß

 

[framp]

Unix hat das Konzept eines Baukastensystems:
1) Einfache kleine Programme, die ihre Aufgabe sehr effizient erfüllen sind die Bausteine
2) Diese Bausteine können entsprechend kombiniert wesentlich komplexere Aufgaben erfüllen (Typisch ist der | Operator der eine Ausgabe zum nächsten Baustein weiterleitet).

Eine Ausnahme ist wenn man extrem auf Performance sehen muss. Deshalb habe ich das winzige C Prog als Kontrapunkt gepostet.

Somit ist seq der richtige Ansatz für den TE.