OSDev.org

Posted: **Thu Jul 05, 2007 2:52 pm**

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

@GLneo
4 Million on Kevins laptop is faster than mine (i think)

Posted: **Thu Jul 05, 2007 2:59 pm**

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

We can guess all day long as we would be still in the same position we are in now..

Posted: **Thu Jul 05, 2007 3:01 pm**

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.

Posted: **Thu Jul 05, 2007 3:05 pm**

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

Posted: **Thu Jul 05, 2007 3:08 pm**

@candy
you didn't modify anything in the code because i don't even get near those values.

Posted: **Thu Jul 05, 2007 3:14 pm**

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 )

Posted: **Thu Jul 05, 2007 3:21 pm**

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.

Posted: **Thu Jul 05, 2007 3:22 pm**

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.

Posted: **Thu Jul 05, 2007 3:27 pm**

i thought system is in <stdlib.h>: http://www.cplusplus.com/reference/clib ... ystem.html

Posted: **Thu Jul 05, 2007 3:32 pm**

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

Posted: **Thu Jul 05, 2007 3:37 pm**

hmm... kmcguire's takes longer but claims higher h/s?, and he accused Brynet-Inc and me of misrepresenting results and underhanded tactics

Posted: **Thu Jul 05, 2007 3:48 pm**

You got me. I apologize. I will keep working on mine.

Posted: **Thu Jul 05, 2007 3:54 pm**

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.

Posted: **Thu Jul 05, 2007 3:55 pm**

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.

Posted: **Thu Jul 05, 2007 4:37 pm**

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.

OSDev.org

brute forcer

Segmentation fault