Posts: 6
Threads: 1
Joined: Jan 2018
01-28-2018, 03:59 PM
(This post was last modified: 01-28-2018, 03:59 PM by Plexus.)
Hi,
I am completely new to hashcat and am trying process as many MD5 hashes of the input "0.################" per second, where '#' is a digit 0-9. The mask I am currently using to attempt this is "0.?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d", however this is significantly slower than if I use the mask "?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d?d" which does not include the prefix. I am aware that the first four characters in the mask should allow for lots of possible combinations to increase GPU utilisation. I have seen that using the ($salt.$pass) variation of the MD5 algorithm can be a possible solution however this has not been the case for me.
Using the non-prefix mask I achieve ~650 MH/s
Using the prefix mask I achieve ~420 MH/s
Using the salt method (-m 20) I achieve ~280 MH/s
Would love to know how I can fix this if possible
Thanks
Posts: 5,185
Threads: 230
Joined: Apr 2010
The strategy to use -m 20 is the right one as -m 20 is around 10-100 times faster than -m 0 if the mask has a static prefix. The reason why this is not in your case is because your prefix is not entirely static. Only 2 of 4 letters are and therefore hashcat is able to get some speed out of it of the remaining 2. There's no other way to speed this up except to hack the kernel and make it use w[1] instead of w[0] for the inner loop iteration.
Posts: 6
Threads: 1
Joined: Jan 2018
(01-28-2018, 07:17 PM)atom Wrote: The strategy to use -m 20 is the right one as -m 20 is around 10-100 times faster than -m 0 if the mask has a static prefix. The reason why this is not in your case is because your prefix is not entirely static. Only 2 of 4 letters are and therefore hashcat is able to get some speed out of it of the remaining 2. There's no other way to speed this up except to hack the kernel and make it use w[1] instead of w[0] for the inner loop iteration.
Sorry for being a pain but what file(s) would I need to edit and is there any resources out there on how to do this?
Posts: 407
Threads: 2
Joined: Dec 2015
"0.################" == winning percentages on online gambling games, verified by md5 hash prior to rolling.
Please stop trying to hack gambling sites. You will not be able to crack the hash before the round ends.
Posts: 6
Threads: 1
Joined: Jan 2018
(01-29-2018, 06:53 AM)Chick3nman Wrote: "0.################" == winning percentages on online gambling games, verified by md5 hash prior to rolling.
Please stop trying to hack gambling sites. You will not be able to crack the hash before the round ends. I'm sorry but it is possible and I have seen it been achieved before. This also has nothing to do with my question.
Posts: 407
Threads: 2
Joined: Dec 2015
The next time you can complete 10^16 on salted md5 fast enough to win a round, let me know. You are looking for 2.77TH/s if the round wait time is roughly an HOUR long. That's 2777000000000 attempts per second to complete the keyspace in an HOUR. Not even in the same league as your achieved max of 650Mh/s(650000000). That's 75 1080Tis or something roughly in that general area of power. And, on top of this being absolutely infeasible, you literally just admitted that you were trying to hack a gambling site. This is not a hacking forum. Please take stuff like this somewhere else.
Posts: 6
Threads: 1
Joined: Jan 2018
(01-29-2018, 07:41 AM)Chick3nman Wrote: The next time you can complete 10^16 on salted md5 fast enough to win a round, let me know. You are looking for 2.77TH/s if the round wait time is roughly an HOUR long. That's 2777000000000 attempts per second to complete the keyspace in an HOUR. Not even in the same league as your achieved max of 650Mh/s(650000000). That's 75 1080Tis or something roughly in that general area of power. And, on top of this being absolutely infeasible, you literally just admitted that you were trying to hack a gambling site. This is not a hacking forum. Please take stuff like this somewhere else.
I don't see where I admitted that I was attempting to "hack" anything, all I said it was possible. You assume that a theoretical winning percentage is hashed using a salt when this is not always the case. Also, who says you need to hash all 10^16 combinations when something like 10^12 is perfectly fine. 10^12 hashes would allow for 1 in 10,000 potential games to be known which is pretty decent if there are a couple of thousand games a day. Also this still has nothing to do with my question.
Posts: 407
Threads: 2
Joined: Dec 2015
Posts: 6
Threads: 1
Joined: Jan 2018
So does anyone know how to modify the kernel to make it use w[1] instead of w[0] inside the inner loop iteration?
Posts: 6
Threads: 1
Joined: Jan 2018
(01-28-2018, 07:17 PM)atom Wrote: The strategy to use -m 20 is the right one as -m 20 is around 10-100 times faster than -m 0 if the mask has a static prefix. The reason why this is not in your case is because your prefix is not entirely static. Only 2 of 4 letters are and therefore hashcat is able to get some speed out of it of the remaining 2. There's no other way to speed this up except to hack the kernel and make it use w[1] instead of w[0] for the inner loop iteration.
So is this the file I am meant to be editing? m00000_a3.cl
If so, in this code what would I need to modify?
Code: __kernel void m00000_sxx (__global pw_t *pws, __global const kernel_rule_t *rules_buf, __global const pw_t *combs_buf, __constant const u32x *words_buf_r, __global void *tmps, __global void *hooks, __global const u32 *bitmaps_buf_s1_a, __global const u32 *bitmaps_buf_s1_b, __global const u32 *bitmaps_buf_s1_c, __global const u32 *bitmaps_buf_s1_d, __global const u32 *bitmaps_buf_s2_a, __global const u32 *bitmaps_buf_s2_b, __global const u32 *bitmaps_buf_s2_c, __global const u32 *bitmaps_buf_s2_d, __global plain_t *plains_buf, __global const digest_t *digests_buf, __global u32 *hashes_shown, __global const salt_t *salt_bufs, __global const void *esalt_bufs, __global u32 *d_return_buf, __global u32 *d_scryptV0_buf, __global u32 *d_scryptV1_buf, __global u32 *d_scryptV2_buf, __global u32 *d_scryptV3_buf, const u32 bitmap_mask, const u32 bitmap_shift1, const u32 bitmap_shift2, const u32 salt_pos, const u32 loop_pos, const u32 loop_cnt, const u32 il_cnt, const u32 digests_cnt, const u32 digests_offset, const u32 combs_mode, const u64 gid_max)
{
/**
* modifier
*/
const u64 lid = get_local_id (0);
const u64 gid = get_global_id (0);
if (gid >= gid_max) return;
/**
* digest
*/
const u32 search[4] =
{
digests_buf[digests_offset].digest_buf[DGST_R0],
digests_buf[digests_offset].digest_buf[DGST_R1],
digests_buf[digests_offset].digest_buf[DGST_R2],
digests_buf[digests_offset].digest_buf[DGST_R3]
};
/**
* base
*/
const u32 pw_len = pws[gid].pw_len;
u32x w[64] = { 0 };
for (int i = 0, idx = 0; i < pw_len; i += 4, idx += 1)
{
w[idx] = pws[gid].i[idx];
}
/**
* loop
*/
u32x w0l = w[0];
for (u32 il_pos = 0; il_pos < il_cnt; il_pos += VECT_SIZE)
{
const u32x w0r = words_buf_r[il_pos / VECT_SIZE];
const u32x w0 = w0l | w0r;
w[0] = w0;
md5_ctx_vector_t ctx;
md5_init_vector (&ctx);
md5_update_vector (&ctx, w, pw_len);
md5_final_vector (&ctx);
const u32x r0 = ctx.h[DGST_R0];
const u32x r1 = ctx.h[DGST_R1];
const u32x r2 = ctx.h[DGST_R2];
const u32x r3 = ctx.h[DGST_R3];
COMPARE_S_SIMD (r0, r1, r2, r3);
}
}
|