OSDev.org

Posted: **Sun Jul 08, 2007 6:43 pm**

accurat timing functions.

Posted: **Sun Jul 08, 2007 7:12 pm**

This may give some performance.


int __fastcall genNextSequence(struct threadInfo * th, const char * charset, const int charset_length) 
{ 
    register int x; 
    register char endchar = (charset_length-1);
    register char *sequence = th->sequence;
    register char *hashKey = th->hashKey;

    for(x = endchar; (sequence[x] == endchar) && (x > 0); --x)
        hashKey[x] = charset[sequence[x] = 0];
    hashKey[x] = charset[++sequence[x]]; 

    // always canâ€™t remember weither in c true == 0.
    return (x == 0); 
}

EDIT: Also change (don't know if it works though, I'm on a computer with know compiler).

Code: Select all

void * start_routine(void * info) {

    struct threadInfo *     th = (struct threadInfo *)info;
    register int loop = th->loop;
    char * hasKey = th->hashKey;
// what is this line for???????
    while(block){sleep(0);}
    
    while(1) {
        if(!genNextSequence(th,charset, sizeof(charset)) )
             break; 
        loop++
        if(md5_hash(th))
            break;
    
    }
    hashKey[th->seqLength] = 0;
}

Posted: **Mon Jul 09, 2007 2:01 am**

i tried the adding the breaks and the while(1) loop in the thread, however it gave no performance boost and more problematic is the fact that the other workers continue after the key has been found. I did however change some addressing of the loop variable after investigating the assembly output and it has improved again. roughly 25 %

The folowing measurements were taken on the Intel Core 2 Duo again.

previous version :

$ time ./brute-old.exe d6a6bc0db10694a2d90e3a69648f3a03 6 2
Collision Found!
hash[d6a6bc0db10694a2d90e3a69648f3a03] = 'hacker'
time: 22.94s
- avg. hash/s: 7405712.60 h/s
#done.

real 0m23.125s
user 0m46.046s
sys 0m0.016s

updated version:

$ time ./brute.exe d6a6bc0db10694a2d90e3a69648f3a03 6 2
Collision Found!
hash[d6a6bc0db10694a2d90e3a69648f3a03] = 'hacker'
time: 17.62s
- avg. hash/s: 9429924.54 h/s
#done.

real 0m17.860s
user 0m35.515s
sys 0m0.015s

i suspect Candy's blackbox will get 10+ Million hashes / second.

Posted: **Mon Jul 09, 2007 2:47 am**

It might melt his CPU.

You had ought to drop it down to twenty or twenty five characters. I imagine no one will do that many either.

Using 26 characters at a length of 10.
(26^10)/10000000/60/60/24 = ~163.38784219140740740741 days

Posted: **Mon Jul 09, 2007 11:01 am**

os64dev wrote:i suspect Candy's blackbox will get 10+ Million hashes / second.

I suspect you'll read about a burnt out house in Tilburg tomorrow.

Ok, I tried it. Last one got 8.9 million just now, the new one got only 3219379.72 h/s on the first try, 2977389.45 h/s on the second one. Let me open some windows and try again in half an hour.

Won't be able to test much more efficient results. It literally overheats within 2 seconds of starting the application:

candy@blackbox:~/brute$ date; time ./brute-mt d6a6bc0db10694a2d90e3a69648f3a03 6 2
Mon Jul 9 19:32:05 CEST 2007
threadList[t].sequence[0]: 0
threadList[t].sequence[0]: 13

Message from syslogd@blackbox at Mon Jul 9 19:32:07 2007 ...
blackbox kernel: CPU1: Temperature above threshold

Posted: **Mon Jul 09, 2007 1:17 pm**

well it can be that the cache is poorly used on the blackbox with the new version or it is the temperature stepping ? I am still waiting for my harddisk so i can test on my AMD X2 4400+ with 2 GiB memory. Well we will see. One advantage candy it not warm outside so you have some free heating

Posted: **Tue Jul 10, 2007 2:34 am**

Ok, again looked over the code namely to fix some bugs. There was a problem with workload balancing: some hashes were calculated more then once. Also the cache utilisation sometimes worked and sometimes not: fixed it by aligning the data structures and prefetching it into memory.

this comes ofcourse at a cost, therefore the new version is a tad slower, in hashes per second, then the previous but it is only about 0.5%.

$ time ./brute.exe d6a6bc0db10694a2d90e3a69648f3a03 6 2
Collision Found!
hash[d6a6bc0db10694a2d90e3a69648f3a03] = 'hacker'
time: 17.70s
- avg. hash/s: 9384329.72 h/s
#done.

real 0m18.000s
user 0m35.686s
sys 0m0.030s

Posted: **Wed Jul 11, 2007 5:47 pm**

found something that might speed things up a little. in c you'll are using the << which compiles into a shl. either you'll can find the opcode and edit it to a rol instruction or find a c equvilant. this would get rid of 2 instructions

Posted: **Wed Jul 11, 2007 6:00 pm**

Ninjarider wrote:found something that might speed things up a little. in c you'll are using the << which compiles into a shl. either you'll can find the opcode and edit it to a rol instruction or find a c equvilant. this would get rid of 2 instructions

Yep, but try making your self a small C program using that ROTATE_LEFT which uses the binary shift operator <<. It will produce, like you said, a couple of instructions doing two shifts and a binary OR-ing. Once you turn on optimization in GCC it disappears by being replaced with a rol instruction.

If you write the program place the ROTATE_LEFT in a small function, and compile with -O0. Then, use objdump -d <object/executable> and locate the function. Last, use -O3, and perform the same steps while after doing so you should notice the difference in the emitted instructions.

Posted: **Wed Jul 11, 2007 9:49 pm**

dont know how possible it is to do. but you'll are wanting the fastest cracking tool.

dont know anything about gcc or how it compiles.

Posted: **Thu Jul 12, 2007 12:31 am**

@ninjarider
trust me. it is already fast and the only method to speed it up is using SSE as mdcrack does. but that is not my intention to do.

Posted: **Thu Jul 12, 2007 3:43 pm**

i would like to see it break 10 m

Posted: **Thu Jul 12, 2007 5:57 pm**

i don't believe its SSE, my old Athlon i don't think has SSE ( just 3dnow! ) and MDcrack still easily doubles our speed.

but on the bright side, this is probably one of the fastest open source cracker, now we need a sourceforge page and add more hash types, and more capability's like http ath brute forcing, nmap style port scanning, etc... then we shall rule the world Muahaha!

Posted: **Thu Jul 12, 2007 6:26 pm**

hmm.. you are getting close to a fine line.

I can tell by your choice of words and phrases. Look how using different words convey a different meaning while still doing the same.

but on the bright side, this is probably one of the fastest MD5 collision finders, now we need a sourceforge page and add more hash types, and do more research leading to better HTTP authentication mechanisms, prevention of non-ethical network information gathering, and such other. Then, we shall actually be able to do something great.

Posted: **Thu Jul 12, 2007 7:16 pm**

yah, but just look at nmap's page, all happy and we are making things secure, but it is obvious what 90% of people will do with it

what else is a "MD5 collision finder" for?, why would administrators want to know their less privileged users passwords

but i do use nmap on my computers every now and then to check for backdoors, so you never know what a tool will be used for.

OSDev.org

brute forcer