AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Projekte TBruteForce - Version 0.5a [Update: 28.04.2008]

TBruteForce - Version 0.5a [Update: 28.04.2008]

Ein Thema von Meflin · begonnen am 25. Aug 2005 · letzter Beitrag vom 13. Jan 2011
Antwort Antwort
Seite 1 von 10  1 23     Letzte » 
Benutzerbild von Meflin
Meflin
Registriert seit: 21. Aug 2003
TBruteForce
Wer hätt's gedacht - eine Brute Force Klasse für Delphi

Aktuelle Version: 0.5a
Download: im Anhang [6,39 KB]



Was ist TBruteForce?

TBruteForce ist eine Klasse, mit der die Implementierung einer BruteForcing-Funktion im eigenen Programm möglichst einfach und gleichzeitig möglichst universell ermöglicht werden soll. Die aktuelle Version verbraucht an sich kaum Arbeitsspeicher (es sei denn der Programmierer entscheidet sich dazu, die erzeugten Kombinationen in irgendeiner Form zwischenzuspeichern). Das bedeutet, dass für die Performance des Vorgangs (abgesehen von der Effektivität des Codes) allein die Prozessorgeschwindigkeit verantwortlich ist.
Bei einem 2GHz Prozessor(kern) liegt die blose Geschwindigkeit bei etwa 50.000.000 Kombinationen pro Sekunde, durch das Zusammensetzen der strings zur Ausgabe verringert sich die Geschwindigkeit auf etwa 2.000.000 Kombinationen pro Sekunde (hier besteht eindeutig Optimierungsbedarf ). Lässt man sich jetzt noch alle Kombinationen sichtbar ausgeben, beispielsweise in einer Konsole, so verringert sich die Geschwindigkeit weiter auf ca. 20.000 Kombinationen pro Sekunde.
So, ich hoffe nun hast Du eine ungefähre Vorstellung in welchen Geschwindigkeitsbereichen man sich mit der Klasse theoretisch und in der Praxis bewegen kann.



Verwendung

Um die Klasse in Betrieb zu nehmen, ist nichts weiter nötig, als die Unit BruteForce.pas in das Projektverzeichnis zu kopieren und in die uses der fraglichen Unit aufzunehmen.
Delphi-Quellcode:
uses
  BruteForce;
Um mit einem einfachen Beispiel zu beginnen: Wir wollen Kombinationen mit 5 Zeichen Länge erzeugen, der Zeichenvorrat soll dabei das Alphabet in Kleinbuchstaben sein. Oder anders ausgedrückt wir wollen alle Kombinationen von aaaaa, aaaab, aaaac, ... bis zzzzx, zzzzy, zzzzz bilden.
Delphi-Quellcode:
var
  BruteForce: TBruteForce;
begin
  // Instanzierung
  BruteForce := TBruteForce.Create;

  // Wir wollen 5 Stellen kombinieren, sg. "Nodes"
  BruteForce.NodeCount := 5;

  // Zeichenvorrat setzen, AlphaLowerCase ist eine Konstante die von der Unit bereitgestellt wird
  // Als ElementList erwartet die Klasse ein array of string. BFConstToDynArray wandelt ein
  // statisches array of string in ein dynamisches array of string um.
  BruteForce.ElementList := BFConstToDynArray(AlphaLowerCase);

  // Soderle. Bereits jetzt enthält BruteForce.Value die erste Kombinationen, in diesem Fall aaaaa.
  // Also müssen wir die gleich ausgeben.
  DoSomething(BruteForce.Value);

  // Jetzt gehts ans eigentliche BruteForcen, wir bilden die Kombinationen
  // BruteForce.NextValue bildet die nächste Kombinationen und gibt das Ergebnis als string zurück
  while not BruteForce.Finished do begin
    DoSomething(BruteForce.NextValue);
  end;

  // Wuppdi - jetzt sind wir schon fertig ;)
Wie viele Kombinationen die Klasse erzeugen wird lässt sich über
BruteForce.ToDo auslesen.


Jetzt ist es aber so, dass man jedem Node seinen eigenen Zeichenvorrat zuweisen kann. D.h. wir könnten beispielsweise auch Kombinationen der länge 5 erzeugen, bei denen die letzten beiden Zeichen Ziffern sind. Das ginge so:
Delphi-Quellcode:
var
  BruteForce: TBruteForce;
begin
  BruteForce := TBruteForce.Create;
  BruteForce.NodeCount := 5;
  BruteForce.ElementList := BFConstToDynArray(AlphaLowerCase);
  // Jetzt kommts ;)
  BruteForce.Nodes[0].ElementList := BFConstToDynArray(Numeric);
  BruteForce.Nodes[1].ElementList := BFConstToDynArray(Numeric);

  DoSomething(BruteForce.Value);

  while not BruteForce.Finished do begin
    DoSomething(BruteForce.NextValue);
  end;
Dieser Code würde alle Kombinationen von aaa00, aaa01,... bis zzz99 ausgeben. Jetzt wunderst Du dich vielleicht, wieso wir den Zeichenvorrat der Nodes 0 und 1 ändern und nicht den der Nodes 3 und 4 (die Zahlen sollen ja rechts hin). Nunja, je weiter ein Node links steht, desto höherwertiger ist er. Deshalb wird der Node, der in der Ausgabe die "rechteste" Stelle repräsentiert über den Index 0 angesprochen. Puh, ich hoffe das ist einigermasen verständlich
Code:
Wort a a a 0 0
Node 4 3 2 1 0

To Do

Bei der Version 0.5a handelt es sich um ein experimentelles Release. Es sind noch kaum Fehlerbehandlungsroutinen eingebaut! Bis jetzt ist es auch so, dass NodeCount unbedingt vor ElementList gesetzt werden muss (ein Henne-Ei-Problem für das ich bis jetzt keine überzeugende Lösung gefunden habe).
Einbauen will ich noch eine Speichern/Laden Funktion, die Möglichkeit, den BruteForce-Vorgang in beliebig viele Pakete aufzuteilen (Multithreading, Parallel Computing), sowie eine Ausgabe der Kombinationen wahlweise als array of string (bzw. TBFElementList). Ich habe auch schon mit dem Gedanken gespielt, beliebige Dinge kombinierbar zu machen (beispielsweise Integer, Objekte, etc). Aber ich bin mir nicht sicher, ob sich der Aufwand lohnen würde.

Ich würde mich freuen, wenn von euch noch Vorschläge und Anregungen kämen, wie man die Komponente noch erweitern könnte



Changelog

Code:
28.04.2008: Version 0.5a "Pandora" released
     Neu: 100% Codebasis ;)
     Kein Multithreading mehr integriert
     Es ist keine Komponente mehr

09.05.2006: Version 0.3b und aktualisierte Demo released
     Neu: Wahl zwischen iterativem und rekurivem Algorithmus
     Neu: TMaxThreads property
     Neu: OnThreadStart Event
     Neu: KeyList jetzt direkt in TBruteForce implementiert, keine 2 Komponenten mehr
     TThreadStatus nicht mehr hardgecodet
     Und alles, was ich inzwischen vergessen habe :(

05.10.2005: Version 0.1.3 Beta RC 2 und aktualisierte Demo released
     Minibugfix beim OnProgressChangeEvent gefixt

03.10.2005: Version 0.1.3 Beta RC 1 und aktualisierte Demo released
     Bugfix: Komponente zählt jetzt richtig
     Bugfix: Memory Leak entfernt
     Performance: Callback Funktion OnProgressChange geht jetzt nicht mehr so auf die Performance

30.08.2005: Version 0.1.2 Beta und aktualisierte Demo released
     Bugfix: das Problem, das das OnLastThreadFinished Event öfter ausgeführt wird sollte behoben sein
     Bugfix: Kleine Unsauberheit beim Progresscounter behoben
     Bugfix: OnProgressChangeTolerance war etwas zu tolerant
     Neu: eine Exception wurde ergänzt

29.08.2005: Demo released

27.08.2005: Version 0.1.1 Beta und neue Demo released
     Bugfix: bei EndLength = 1 werden jetzt nicht mehr fälschlicherweise die 2-stelligen Keys erzeugt
     Neu: Event OnProgressChange
     Neu: public property OnProgressChangeTolerance
     Neu: Exception Handling

26.08.2005: Demo released

25.08.2005: Version 0.1 Beta released
Angehängte Dateien
Dateityp: rar tbruteforce.0.3b_108.rar (4,2 KB, 643x aufgerufen)
Dateityp: pas bruteforce_207.pas (6,4 KB, 346x aufgerufen)
 
Daniel G
 
#2
  Alt 25. Aug 2005, 14:02
Hey, nicht schlecht

Mal eine etwas andere Komponente. Auch wenn die Funktionen größtenteils ja selbsterklärend sind, wäre ein kleines Beispielprogramm nicht schlecht.
  Mit Zitat antworten Zitat
Benutzerbild von Stanlay Hanks
Stanlay Hanks

 
Delphi 2005 Professional
 
#3
  Alt 25. Aug 2005, 14:09
Zitat von Meflin:
Achtung: BrutForce.Stop sollte nur im Notfall verwendet werden, da diese Methode TerminateThread und damit all dessen Nebenwirkungen beinhaltet
Hi Meflin Nur so Interesse halber, welche "Nebenwirkungen" wären das denn?
  Mit Zitat antworten Zitat
Benutzerbild von Meflin
Meflin
 
#4
  Alt 25. Aug 2005, 14:13
@Stan:
Zitat von MSDN:
TerminateThread can result in the following problems:
  • If the target thread owns a critical section, the critical section will not be released.
  • If the target thread is allocating memory from the heap, the heap lock will not be released.
  • If the target thread is executing certain kernel32 calls when it is terminated, the kernel32 state for the thread's process could be inconsistent. [tut meiner afaik nicht]
  • If the target thread is manipulating the global state of a shared DLL, the state of the DLL could be destroyed, affecting other users of the DLL. [tut meiner nicht]
@Daniel G: das wird sich machen lassen

Leo S.
  Mit Zitat antworten Zitat
Benutzerbild von MisterNiceGuy
MisterNiceGuy

 
Delphi 7 Personal
 
#5
  Alt 25. Aug 2005, 14:21
Schneller!! Her mit der Demo

Ah doch, habs schon kapiert
Jonas
  Mit Zitat antworten Zitat
Benutzerbild von SirThornberry
SirThornberry

 
Delphi 2006 Professional
 
#6
  Alt 25. Aug 2005, 14:26
Seh ich das richtig das alle Varianten dann in eine Liste gespeichert werden? Oder wird die Liste immer erst gefüllt wenn man was rausnimmt? Wenn dem nicht so isst dürfte der Speicherverbrauch etwas sehr groß sein bis hinn zum Absturz des Programmes weil der Speicher nicht reicht.
Jens
  Mit Zitat antworten Zitat
Benutzerbild von MisterNiceGuy
MisterNiceGuy

 
Delphi 7 Personal
 
#7
  Alt 25. Aug 2005, 14:36
Hab mal ne Demo erstellt die nur die einfachsten Funktionen nutzt.
Angehängte Dateien
Dateityp: zip brute_force_170.zip (219,5 KB, 333x aufgerufen)
Jonas
  Mit Zitat antworten Zitat
Benutzerbild von Meflin
Meflin
 
#8
  Alt 25. Aug 2005, 14:38
Zitat von SirThornberry:
Seh ich das richtig das alle Varianten dann in eine Liste gespeichert werden? Oder wird die Liste immer erst gefüllt wenn man was rausnimmt? Wenn dem nicht so isst dürfte der Speicherverbrauch etwas sehr groß sein bis hinn zum Absturz des Programmes weil der Speicher nicht reicht.
Im Prinzip führt es zum Absturz, wenn der Anwender nix mit den Keys macht ja. Ich habe auch schon überlegt ob ich so eine Art backward-Steuerung einbaue sprich aber einer bestimmten Anzahl Keys in TKeyList hält TKeyList TBrutForce an, und wenn wieder weniger Keys drin sind setzt sie TBruteForce fort. Das wäre kein großer Aufwand, die Frage ist, ob der Bedarf besteht.

@Mister: Freut mich dass das Ding so einfach ist dass man ohne Hilfe ein Demo damit bauen kann

Leo S.
  Mit Zitat antworten Zitat
Benutzerbild von SirThornberry
SirThornberry

 
Delphi 2006 Professional
 
#9
  Alt 25. Aug 2005, 14:41
ich würde eher vorschlagen das du die X'te Variante erst bei der Abfrage berechnest.
Denn so wie es Oktal, Hexdezimal, Dezimal gibt kannst du auch einfach die erlaubten zeischen handhaben und somit auch den Key schnell zusammenbauen wenn die Variante 5329393 abgefragt wird.
Jens
  Mit Zitat antworten Zitat
Benutzerbild von Meflin
Meflin
 
#10
  Alt 25. Aug 2005, 14:48
Zu Mister Nice Guys Demo:
So ganz tut sie nicht was sie verspricht Man kann zwar zur Laufzeit Angaben machen, allerdings werden die nicht verwendet, sondern die, die Mister reincomiliert hat...
Wenn du jetzt noch das OnLastThreadFinished Event von TBruteForce verwendest, um das "Anzeigen" automatisch durchzuführen, und die Property BruteForce.Percentage um den Fortschritt anzuzeigen, dann hast du im großen und ganzen alles drin.

@Sir: das dürfte mit meiner verwendeten Methode so nicht durchführbar sein. Um den Xten Key zu bekommen, muss immer erst der X-1nte erzeugt werden. Insofern sehe ich den Sinn dann nciht so ganz

Leo S.
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 10  1 23     Letzte » 

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 23:14 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz