brute forcer

Programming, for all ages and all languages.
User avatar
os64dev
Member
Member
Posts: 553
Joined: Sat Jan 27, 2007 3:21 pm
Location: Best, Netherlands

Post by os64dev »

@candy
what kind of system did you ran it on.

@GLneo
4 Million on Kevins laptop is faster than mine (i think)
Author of COBOS
User avatar
Kevin McGuire
Member
Member
Posts: 843
Joined: Tue Nov 09, 2004 12:00 am
Location: United States
Contact:

Post by Kevin McGuire »

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.
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.. :x

We can guess all day long as we would be still in the same position we are in now..
User avatar
Candy
Member
Member
Posts: 3882
Joined: Tue Oct 17, 2006 11:33 pm
Location: Eindhoven

Post by Candy »

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$
I'm not sure I like that "segmentation fault", but it's nearly as fast. I can't say what the problem could be, but could you make a larger problem? this one is messing with loading times and rounding times and so on because it's so short.
User avatar
Candy
Member
Member
Posts: 3882
Joined: Tue Oct 17, 2006 11:33 pm
Location: Eindhoven

Post by Candy »

os64dev wrote:@candy
what kind of system did you ran it on.

@GLneo
4 Million on Kevins laptop is faster than mine (i think)
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)

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
User avatar
os64dev
Member
Member
Posts: 553
Joined: Sat Jan 27, 2007 3:21 pm
Location: Best, Netherlands

Post by os64dev »

@candy
you didn't modify anything in the code because i don't even get near those values.
Author of COBOS
GLneo
Member
Member
Posts: 237
Joined: Wed Dec 20, 2006 7:56 pm

Post by GLneo »

the segmentation fault might be the

Code: Select all

system("pause");
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 )
Last edited by GLneo on Thu Jul 05, 2007 3:21 pm, edited 1 time in total.
User avatar
Candy
Member
Member
Posts: 3882
Joined: Tue Oct 17, 2006 11:33 pm
Location: Eindhoven

Post by Candy »

os64dev wrote:@candy
you didn't modify anything in the code because i don't even get near those values.
Let's see... I modified everybody's code since none would compile.

Code: Select all

candy@blackbox:~/brute$ diff -w brute.cc ../Desktop/brute.cc
6d5
< #include <stdint.h>
candy@blackbox:~/brute$                      
You used uint32_t without stdint.h -> include stdint.h. That's all.
User avatar
Candy
Member
Member
Posts: 3882
Joined: Tue Oct 17, 2006 11:33 pm
Location: Eindhoven

Post by Candy »

GLneo wrote:the segmentation fault might be the

Code: Select all

system("pause");
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 )
I had to remove that line since you didn't include a header for system(). That could be why it crashes.
GLneo
Member
Member
Posts: 237
Joined: Wed Dec 20, 2006 7:56 pm

Post by GLneo »

User avatar
Candy
Member
Member
Posts: 3882
Joined: Tue Oct 17, 2006 11:33 pm
Location: Eindhoven

Post by Candy »

New stats!

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
GLNeo's cocaine.c:

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
os64dev's brute.cc:

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
GLneo
Member
Member
Posts: 237
Joined: Wed Dec 20, 2006 7:56 pm

Post by GLneo »

hmm... kmcguire's takes longer but claims higher h/s?, and he accused Brynet-Inc and me of misrepresenting results and underhanded tactics :P
User avatar
Kevin McGuire
Member
Member
Posts: 843
Joined: Tue Nov 09, 2004 12:00 am
Location: United States
Contact:

Post by Kevin McGuire »

You got me. I apologize. I will keep working on mine.
User avatar
os64dev
Member
Member
Posts: 553
Joined: Sat Jan 27, 2007 3:21 pm
Location: Best, Netherlands

Post by os64dev »

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
User avatar
jhawthorn
Member
Member
Posts: 58
Joined: Sun Nov 26, 2006 4:06 pm
Location: Victoria, BC, Canada
Contact:

Segmentation fault

Post by jhawthorn »

I didn't have a good look into this, but quickly noticed that reversing the order of

Code: Select all

unsigned char digest[16];
unsigned char raw_inhash[16];
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.
Last edited by jhawthorn on Thu Jul 05, 2007 11:08 pm, edited 1 time in total.
User avatar
Kevin McGuire
Member
Member
Posts: 843
Joined: Tue Nov 09, 2004 12:00 am
Location: United States
Contact:

Post by Kevin McGuire »

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:
  • loops to change the most significant sequence byte. (threading)
  • loops to cycle between sequence lengths. (threading)
  • minor differences in the core *computation* loop.
I have found the reason my hashes per second were higher. When calculating the hashes per second I use:
(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.
Post Reply