Quantcast
Channel: hashcat Forum - All Forums
Viewing all articles
Browse latest Browse all 7673

Some questions.

$
0
0
Hello, got some questions, eager to know the answers.

1. what type of password openCL kernel receives from hashcat - BE or LE? Does OPTS_TYPE_PT_GENERATE_BE in opts have something to do with it?

2. bruteforce kernels mutate w0 4-byte block like that:
const u32x w0 = w0l | w0r;
why is that only 1 block in the beginning? how does it work when we want to mutate 2nd, 3d, etc block?

3. I've seen 2 types of bruteforce mutations, why is that, what's better?
*    const u32x w0r = ix_create_bft (bfs_buf, il_pos);
*    const u32x w0r = words_buf_r[il_pos / VECT_SIZE];

4. what does OPTS_TYPE_ST_ADDBITS15 mean? Does it put salt_len in s15?

5. if the password is in BE can I use switch_buffer_by_offset_le_VV (w0, w1, w2, w3, len );? There's no function switch_buffer_by_offset_le_VV, only the one without vectoring.

6. what is vectoring? is it like parallel execution on GPU?


Actually, at first I thought I get it, but now I'm confused with endianness. 
Let's take m100_a0 as an example, it has
opts_type = OPTS_TYPE_PT_GENERATE_BE
| OPTS_TYPE_PT_ADD80
| OPTS_TYPE_PT_ADDBITS15;


Lets take these lines
    u32x wd_t = swap32 (w3[1]);
    u32x we_t = 0;
    u32x wf_t = out_len * 8;

Why do we swap pw? I thought it supposed to be generated in BE, and sha-1 operates on BE blocks.
But maybe PW is not BE? Then another question, the length should be in 64-bit BE, but here we have it in LE 32-bit.
It probably works by swapping every wX_t once again somewhere else, right?


Really big thanks for any answer! Trying hard to understand these intrinsics.

Viewing all articles
Browse latest Browse all 7673

Trending Articles