MD5 Cracker für GPU?

easteregg

easteregg

0
heyho

gibts eigentlich mittlerweile freeware/opensource cracker, welche die GPU mit einbinden, um die hashes zu knacken?
ich bin nur über das produkt von elcomsoft gestoßen, das ist ja zum einen nicht frei verfügbar und zum anderen bin ich scheinbar zu dumm, ne neue aufgabe für nen md5 file in der demo zu erstellen.

(OT: welches format muss die *.md5 datei haben?!/OT)

gibts da mittlerweile alternativen?
 
Sowas kann man patentieren lassen?
Das tönt für mich etwas zu, naja, simpel für ein Patent.

Wenn ich auf die Idee komme, um mein Haus zu lüften nicht nur die Tür sondern auch ein Fenster zu öffnen kann ich das ja auchnicht als Patent anmelden...

?(
 
Tja die Frage ist genau was da Patentiert wurde die Idee oder die ähnliche Implementierung. Soviel zu Trivialpatenten.

OT: Wäre ein Cluster z.B. PS2/3 oder per Boinc nicht eine bessere Lösung? Oder gleich selber bauen per FPGA: http://wiki.thc.org/cracking_a5 (ok ok "nur" A5)
 
Hallo,
@starfoxx: Die Lange in den USA ist da noch deutlich anders als hier in Deutschland und nur weil dort etwas patentiert ist, muss dieses Patent nicht unbedingt hier bestand haben. Wie es aber indem Fall ist, weiß ich nicht.
In Deutschland kann man, afaik, keine reihnen Ideen patentieren, z.B. kann man sich ein (Web) Menü auf der rechten Seite der Site sich nicht patentieren lassen.

Ansonsten wäre ich auch intressiert an solch einem Programm, hatte mir mal vorgenommen soetwas versuchen selber zu schreiben, bisher aber noch gar keine Zeit dafür gefunden.

Hab mal bei SourceForge gesucht: Suche nach GPU

Der erste Suchtreffer, OpenGpuLib sieht doch schonmal vielversprechend aus.

@AcoQ: Was meinst du mit deinem Beitrag?
Auf Rainbowtables zurückzugreifen ist nicht immer der ideale Weg, es gibt Passwörter die in keiner Rainbowtable zu finden sind, aber per Brute Force wären die in einer akzeptablen Zeit geknackt.
 
Ich dachte, ab einer gewissen Wahrscheinlichkeit eines Treffers innerhalb der Rainbowtable, wäre die RT zu bevorzugen.
Zur OpenGpuLib: Wird seit 2004 nicht mehr entwickelt, ist es nicht besser z.B. das ATi Framework zu nutzen?
 
Hmm, man könnte da was mit Shadern drehen denke ich.

Natürlich nicht mit Vertexshadern, sondern mit Fragmentshadern...
man könnte einfach den MD5-Cracker auf GLSL portieren, als Fragmentshader ausführen... das ganze müsste über mehrere globale GLSL-Variablen koodiniert werden, als eine Art Heap wird einfach der Framebuffer missbraucht... :D

Und schon sendet die CPU nur noch eine 8x1 Pixel große Textur (bei 32 BPP ergibt das 32 Byte, daher einen MD5 Hash in Hexadezimaldarstellung) an die GPU, bindet vorher die Shader, und ab geht die Post :D

Danach per glReadPixels das Ergebniss aus dem Framebuffer zurücklesen.
voilá!

Das wäre meine Idee zu dem Thema...
 
Original von csde_rats
Hmm, man könnte da was mit Shadern drehen denke ich.

Natürlich nicht mit Vertexshadern, sondern mit Fragmentshadern...
man könnte einfach den MD5-Cracker auf GLSL portieren, als Fragmentshader ausführen... das ganze müsste über mehrere globale GLSL-Variablen koodiniert werden, als eine Art Heap wird einfach der Framebuffer missbraucht... :D

Und schon sendet die CPU nur noch eine 8x1 Pixel große Textur (bei 32 BPP ergibt das 32 Byte, daher einen MD5 Hash in Hexadezimaldarstellung) an die GPU, bindet vorher die Shader, und ab geht die Post :D

Danach per glReadPixels das Ergebniss aus dem Framebuffer zurücklesen.
voilá!

Das wäre meine Idee zu dem Thema...
Zum Vergrößern anklicken....

Ich denke das ist etwas umständlich. AcoQ hat oben schon den richtigen tipp gegeben. CUDA oder BROOK verwenden. BROOK hab ich selbst noch nicht gemacht. Zu CUDA kann ich sagen, dass es recht schnell erlenbar ist und die erzielten ergebnisse unglaublich performant sind.
Als Basis für die Implementierung würde ich die md5-Referenzimplementierung von Peter Deutsch empfehlen. Das ist die schnellste md5-variante, die mir bekannt ist (bitte gebt mir nen tipp, wenns da noch was besseres gibt).
 
CUDA wirkt auf mich um einiges ausgereifter. Problem ist, dass ich eine ATi Karte nutze (Brook+ macht einen sehr "unaufgeräumten" Eindruck).
 
Original von AcoQ
CUDA wirkt auf mich um einiges ausgereifter.
Zum Vergrößern anklicken....

Ich würde CUDA jetzt nicht in den Himmel loben. Da gibts auch so einige Ecken und Kanten.
Habs zum Beispiel nicht geschafft die von dem mitgelieferten compiler aus dem SDK (ist glaub nen umgebauter gcc, soviel also zum Thema GPL) generierten *.o in mein vstudio-projekt zu linken. hab dann also für das ganze projekt nen custom-buildstep gemacht und alles mit dem cuda-compiler gemacht. Das problem dabei war, dass vstud sobald man nicht den embedded-compiler verwendet kein syntaxhighlighting und kein intellisense mehr macht. Das ist nicht unbedingt toll.

Mir ist auch aufgefallen, dass solange nen Kernel auf der GPU läuft, auch die CPU, die den Kernel gestartet hat auf 100% ackert.
Fand das ziemlich ekelig, da ein Thread zu einem Zeitpunkt immer nur auf einer Karte Kernels starten kann. Somit hatte ich bei 2 Karten immer 2 Kerne des QuadCore unter volllast, obwohl die nix weiter gemacht haben ausser Kernels auf den GPU's zu starten oder nen paar cudaMemCpy's und dann busy zu waiten, bis die endlich mal fetig werden. Das waren dann also ca. 99% busy wait.

Kann mir jemand erklären, warum das so ist und evtl. wie man das verhindern kann?
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben