brute forcer
- Kevin McGuire
- Member
- Posts: 843
- Joined: Tue Nov 09, 2004 12:00 am
- Location: United States
- Contact:
You said it ups it, but we need to know from what? I mean more information in these cases is better. We also need to know about this P4 processor you have..Removing what I thought might be good and adding -march=i686 (on a p4) ups this to 5.5 million. Adding -fomit-frame-pointer ups that to 5.7 million. This is still on a single core.
We can guess all day long as we would be still in the same position we are in now..
Code: Select all
Collision Found!: 5b9104dc42e2f8fdd3f6a801f7656d65 is : glich
Cracking took: 0.61s
Average h/s: 5310957.39 h/s
Segmentation fault
real 0m0.613s
user 0m0.613s
sys 0m0.000s
candy@blackbox:~/brute$
Intel Pentium D 805, dual core but the program is single threaded. Optimizing for nocona (which it is), prescott or pentium4 gives 5.4 million; for ppro, i686, pentium2, pentium3 gives 5.6 million. Adding -fomit-frame-pointer to i686 gives it 5.7 million (about), but I can't get it higher. Exceptions & rtti don't give any overhead (apparently)os64dev wrote:@candy
what kind of system did you ran it on.
@GLneo
4 Million on Kevins laptop is faster than mine (i think)
Bit of extra info:
Dual channel ram, 1066 mhz bus, 1GB available (but I doubt you can even allocate that in 0.6 seconds), really quick harddisk that shouldn't matter because of memory caching, 2666mhz processor speed (iirc). Big fat cooler that keeps it cool enough to run at full speed.
Lemme rerun the tests for real numbers.
Code: Select all
candy@blackbox:~/brute$ g++ brute.cc -finline-functions -fno-exceptions -fno-rtti -fomit-frame-pointer -lm -lpthread -O3 -march=i686 -o brute && time ./brute 5b9104dc42e2f8fdd3f6a801f7656d65 5
Collision Found!
hash[5b9104dc42e2f8fdd3f6a801f7656d65] = 'glich'
- time: 0.56s
- avg. hash/s: 5785150.00 h/s -> fastest I've seen, occasionally drops to 5.68, averages on this value though
real 0m0.576s
user 0m0.569s
sys 0m0.005s
candy@blackbox:~/brute$ g++ brute.cc -finline-functions -fno-exceptions -fno-rtti -lm -lpthread -O3 -march=i686 -o brute && time ./brute 5b9104dc42e2f8fdd3f6a801f7656d65 5
Collision Found!
hash[5b9104dc42e2f8fdd3f6a801f7656d65] = 'glich'
- time: 0.57s
- avg. hash/s: 5683656.14 h/s -> this one doesn't get higher than this
real 0m0.579s
user 0m0.577s
sys 0m0.002s
candy@blackbox:~/brute$ g++ brute.cc -finline-functions -fno-exceptions -fno-rtti -lm -lpthread -O3 -march=nocona -o brute && time ./brute 5b9104dc42e2f8fdd3f6a801f7656d65 5
Collision Found!
hash[5b9104dc42e2f8fdd3f6a801f7656d65] = 'glich'
- time: 0.60s
- avg. hash/s: 5399473.33 h/s -> which is just plain odd.
real 0m0.604s
user 0m0.591s
sys 0m0.011s
the segmentation fault might be the because it closes instantly without it in Win xp
because our programs are so fast now lets works with this md5 sum d6a6bc0db10694a2d90e3a69648f3a03 ( 6 lower-alpha letters )
Code: Select all
system("pause");
because our programs are so fast now lets works with this md5 sum d6a6bc0db10694a2d90e3a69648f3a03 ( 6 lower-alpha letters )
Last edited by GLneo on Thu Jul 05, 2007 3:21 pm, edited 1 time in total.
Let's see... I modified everybody's code since none would compile.os64dev wrote:@candy
you didn't modify anything in the code because i don't even get near those values.
Code: Select all
candy@blackbox:~/brute$ diff -w brute.cc ../Desktop/brute.cc
6d5
< #include <stdint.h>
candy@blackbox:~/brute$
I had to remove that line since you didn't include a header for system(). That could be why it crashes.GLneo wrote:the segmentation fault might be thebecause it closes instantly without it in Win xpCode: Select all
system("pause");
because our programs are so fast now lets works with this md5 sum d6a6bc0db10694a2d90e3a69648f3a03 ( 6 lower-alpha letters )
i thought system is in <stdlib.h>: http://www.cplusplus.com/reference/clib ... ystem.html
New stats!
kmcguire's md5.c:
GLNeo's cocaine.c:
os64dev's brute.cc:
kmcguire's md5.c:
Code: Select all
candy@blackbox:~/brute$ g++ md5.c -g -fomit-frame-pointer -finline-functions -fno-exceptions -fno-rtti -lm -lpthread -O3 -march=i686 -o md5 && time ./md5 d6a6bc0db10694a2d90e3a69648f3a03 6 6
initializing..
digest_target is 0dbca6d6a29406b1693a0ed9033a8f64
h/s:5556515.127660
(1) I found a collision!
message:hacker
g_thread_active_cnt:0
real 0m48.051s
user 0m47.387s
sys 0m0.170s
Code: Select all
candy@blackbox:~/brute$ g++ cocaine.c -fomit-frame-pointer -finline-functions -fno-exceptions -fno-rtti -lm -lpthread -O3 -march=i686 -o cocaine && time ./cocaine d6a6bc0db10694a2d90e3a69648f3a03 6
Collision Found!: d6a6bc0db10694a2d90e3a69648f3a03 is : hacker
Cracking took: 38.95s
Average h/s: 5237186.52 h/s
Segmentation fault (core dumped)
real 0m39.152s
user 0m38.811s
sys 0m0.150s
Code: Select all
candy@blackbox:~/brute$ g++ brute.cc -fomit-frame-pointer -finline-functions -fno-exceptions -fno-rtti -lm -lpthread -O3 -march=i686 -o brute && time ./brute d6a6bc0db10694a2d90e3a69648f3a03 6
Collision Found!
hash[d6a6bc0db10694a2d90e3a69648f3a03] = 'hacker'
- time: 36.19s
- avg. hash/s: 5636596.16 h/s
real 0m36.294s
user 0m36.046s
sys 0m0.155s
- Kevin McGuire
- Member
- Posts: 843
- Joined: Tue Nov 09, 2004 12:00 am
- Location: United States
- Contact:
well he uses threads which have a rather large startup time. but yeah it kind a difficult to comprehend yet there is nothing wrong with his code. though running tests with multi threading my clock() went haywire.
Author of COBOS
Segmentation fault
I didn't have a good look into this, but quickly noticed that reversing the order of
Causes a segfault under -O3 and "Collision NOT Found" under -O0.
Again, I didn't get the chance to look at the code in detail, sorry.
This is under os64dev's version, but I bet they all have the same general problem.
Code: Select all
unsigned char digest[16];
unsigned char raw_inhash[16];
Again, I didn't get the chance to look at the code in detail, sorry.
This is under os64dev's version, but I bet they all have the same general problem.
Last edited by jhawthorn on Thu Jul 05, 2007 11:08 pm, edited 1 time in total.
- Kevin McGuire
- Member
- Posts: 843
- Joined: Tue Nov 09, 2004 12:00 am
- Location: United States
- Contact:
I decided to keep looking for my problem, and why the statistics are so skewed for my implementation. You guy's implementation's are actually faster, but this is attributed:
(float)loop / (clock() - g_start) / (float)CLOCKS_PER_SEC);
When you guys calculate the hashes per second you use (since you share the same code base):
float dif = (end - start);
dif /= CLOCKS_PER_SEC;
If I use your way of calculating hashes cocaine.c produces 2.9 million per second on a five byte message, while mine produces 2.3 million per second on a five byte message - which clearly shows mine is slower.
- loops to change the most significant sequence byte. (threading)
- loops to cycle between sequence lengths. (threading)
- minor differences in the core *computation* loop.
(float)loop / (clock() - g_start) / (float)CLOCKS_PER_SEC);
When you guys calculate the hashes per second you use (since you share the same code base):
float dif = (end - start);
dif /= CLOCKS_PER_SEC;
If I use your way of calculating hashes cocaine.c produces 2.9 million per second on a five byte message, while mine produces 2.3 million per second on a five byte message - which clearly shows mine is slower.