code optimierung

[Bonkers]

void btf(int size, int pos, char curr[]) { // size = Aktuelle Länge; pos = Aktuelle Position; curr = Das aktuelle Passwort
char* charset = "ABCDEFGHIJKLMNOPQRSTUVWXYZ123456789"; // Das Charset halt :D
int i;
if(pos < size){ // Wenn wir noch nicht beim letzen Buchstaben sind...
for(i=0; i<strlen(charset);i++){ // Gehe das ganze Charset durch...
        char test[strlen(curr) + 2]; //Hänge die Buchstaben hinten an...
        strcpy(test, curr);
        int len = strlen(test);
        test[len] = charset[i];
        test[len+1] = '\0';
        btf(size, pos+1, test); // Wir sind ja nicht beim letzten Buchstaben, also rufen wir uns selbst auf. Wenn der letzte Buchstabe erreicht ist, dann gehen wir wegen der For oben im Charset eins weiter. Das macht natürliche jede Instanz von BTF, und somit kommst du auf alle Möglichkeiten.
}} else { // wir haben ein Passwort generiert!
	if(match(crackme, curr) == 1) { // Passt der Hash?
	printf("Your Hash has been Cracked. md5( %s ) == %s\n", curr, crackme); // Ausgabe, wir haben was gecracked!
	exit(0);
	}
	}
}

In der Hinsicht hin ist sein Source Code wesentlich perdormanter als deiner.

Mir geht es auch absolut nicht um Geschwindigkeit, sondern eher um die Rekursiven Funktionen. Wenn ich was cracken will dann löse ich das über einen GPU-Cracker...

[Gaara]

was ist aber wenn ich das ganze angeh wie bei meiner funktion, d.h. alle nachteile ausbügle aber das ganze rekursiv löse? bin ich dann nur flexibler oder auch schneller?

//edit

wow, danke bonkers für die kommentierung, das hilft mir sehr

[EBFE]

1. keine Kopierereien und "höhere" Datentypen wie Strings (ein "string[x]" Zugriff artet nämlich intern in einige Calls aus und ist keineswegs mit dem "char* hallo[x]" gleichzusetzen). Gleiches gilt für "Concatenierungen" oder gar "+" Operatoren bei Strings.
nimm ein chararray, initialisiere es am Anfag mit 0 und schreibe direkt die Zeichen rein.

2. alle Infos möglichst im voraus berechnen - so auch die Passwortlänge.
3. MD5 Routine aus den Libs ist keineswegs optimal - denn diese sind dazu gedacht, "echte" Daten zu hashen. Sofern man aber auf 12-13 Zeichen beschränkt ist, kann man einiges wegoptimieren:
das ist nämlich der Algo:
Message-Digest Algorithm 5 – Wikipedia
z.B dieser Schritt:

b := ((a + f + k(i) + w(g)) leftrotate r(i)) + b

also das einbeziehen der Eingabe (=w(g) Wert):

so schaut der Speicherzugriff bei 20 Zeichen und 64 Runden:

54 ?- show_mem(20, 64).

0000:                  0                 1                 2                 3
0004:                  4                 5                 6                 7
0008:                  8                 9                10                11
0012:                 12                13               len                15
0016:                  1                 6                11                 0
0020:                  5                10                15                 4
0024:                  9               len                 3                 8
0028:                 13                 2                 7                12
0032:                  5                 8                11               len
0036:                  1                 4                 7                10
0040:                 13                 0                 3                 6
0044:                  9                12                15                 2
0048:                  0                 7               len                 5
0052:                 12                 3                10                 1
0056:                  8                15                 6                13
0060:                  4                11                 2                 9

Zahlen links: aktuelle Runde im Hashalgo, Zahl in der Zeile = Zugriff auf Adresse x in der jeweiligen Runde, LEN ist dabei "Extrabezeichner" für den Zugriff auf den Speicher mit der Längenangabe.

und so bei 4 Zeichen:

53 ?- show_mem(4, 64).

0000:                  0                 1                 2                 3
0004:                  4                []                []                []
0008:                 []                []                []                []
0012:                 []                []               len                []
0016:                  1                []                []                 0
0020:                 []                []                []                 4
0024:                 []               len                 3                []
0028:                 []                 2                []                []
0032:                 []                []                []               len
0036:                  1                 4                []                []
0040:                 []                 0                 3                []
0044:                 []                []                []                 2
0048:                  0                []               len                []
0052:                 []                 3                []                 1
0056:                 []                []                []                []
0060:                  4                []                 2                []

Zahlen links: aktuelle Rundennummer, Zahlen in der Zeile: Zugriff auf Adresse x in der jeweiligen Runde. [] bedeutet dass hier Zugriff auf 0-initialisierten Speicher stattfand, d.h dass man diesen auch ignorieren kann, da ja eine 0 hinzuaddiert werden sollte)

hier kann man sich also jede Menge Speicherzugriffe sparen.
Zudem lassen sich die letzen 15-18 der 64 Runden (länger her) zurückrechnen, was wiederum eine "Verschnellerung" um 25% bietet. Den ultimativen Boost bringt aber Parallelisierung mittels MMX oder gleich SSE:
Software optimization resources. C++ and assembly. Windows, Linux, BSD, Mac OS X
(hier solltest du, je nach Kenntnissstand, ruhig einige Wochen zum durcharbeiten einplanen )
Damit erreicht man mehere zig Mio Hashs pro Sekunde (z.B auf meinem 3 Jahre altem Laptop 32 Mio Hashs/s pro Kern - gegenüber BarsWFs 27 Mio H/s ). Setzt aber voraus, dass man sich mit SSE erstmal beschäftigt (C++ Compiler wird hier einem keineswegs die Arbeit abnehmen - vielleicht nur insofern, dass er die SSE Register selbstständig vergibt, allerdings muss man dem Compiler an vielen Schritten zu seinem "Glück" verhelfen. Letzendlich schaut der hochoptimierte Code wie Macro-Asm aus:
Distracted: New and faster EmDebr finally done
(Md5 cracker mit Source, unwesentlich langsamer als BarsWF)

4. Nicht zuletzt solltest du dich mit Profilersoftware vertraut machen, um die tatsächlichen Problemstellen zu finden. Zumindest eine gute Timerbibliothek suchen und einbauen, so dass man die Zeit für einzelne Abschnitte messen kann und so abschätzen, was am meisten Rechenzeit kostet und optimiert werden muss.

[Gaara]

wow, danke für diesen post.. is ja mal hammer.
da werd ich mich mal durcharbeiten, auch wenns viel arbeit wird^^ aber ich hab gemerkt dass plumpes lesen und sich seine gedanken machen nicht sonderlich viel hilft... deswegen stürz ich mich ins coden :x so lernt man am besten^^ den unteren abschnitt werd ich da natürlich erstmal etwas hinten anstellen da sich das sehr komplex anhört, erstmal will ich die basics perfekt drauf haben.

aber nochmal zurück zu den letzten posts... ich hab das jetzt auf rekursiv und char umgestellt (auch wenn nochnicht perfekt, hatte einfach kein kopf mehr) aber im vergleich zu meiner funktion hab ich nen enormen performance verlusst... manche einfache hashs kamen nichtmal zu nem ergebnis weils mir einfach zu lang dauerte wo meine funktion knapp ne minute gebraucht hat. deswegen frag ich mich... hat meine funktion nen fehler oder ist die rekursive methode vllt. doch nicht so effektiv?

und meine 2. frage is... enden rekursive funktionen die zu lang laufen (wie z.b. wenn ich damit alle 20 stelligen hashs berechne) nicht in nem stackoverflow? schließlich landet doch jeder wieder aufruf oben aufm stack und der erste aufruf bleibt ganz unten liegen. versteh ich da was falsch oder is das tatsächlich ein nachteil?

[0x30]

Rekursiv ist afaik sehr langsam.

[ocz]

Rekursiv ist afaik sehr langsam.

Würde Sinn ergeben, vor Allem aufgrund der vielen calls, pushs und pops