hashcat and HMAC-SHA256 ...
I was looking for a tool to brute forcing a password that use HMAC-SHA256.
My first thought was "hashcat", which easily supports HMAC-SHA256 but there is a problem: it does not support more than 256 characters as "message". My message is more than 7000 characters long. Exists a patch or other software similar to hashcat ? Now I use python for brute force but it is definitely slow ... :eek: |
You might try to recompile hashcat with more chars allowed. Or read HMAC-SHA256 specification, as it should read "chunks", so You might be able to use this info with Your problem
|
I've already tried to recompile hashcat by increasing the number of possible characters from 256 to 8192, but the software crashes. I tried to figure out where the problem may be but without success.
I read the specification and it doesn't seem complicated, but I should put a lot of hashcat code back to adapt it to the new length. I thought there was something else like it, but I didn't find anything. Some idea ? |
First off the relevant file for this change (assuming you are using the 1450 variant which it sure sounds like you are) - size independent files:
Quote:
Quote:
Code:
typedef struct pw I don't know why it would crash - perhaps you can use a debugger and give the source code line upon which it crashes. I am assuming you are using OpenCL and not GPU though I would have imagined they would share definitional source. It does call sha256_hmac_init_swap which has special handling above 64 size - the truncation to 8 bytes looks strange and maybe this is untested given the buffer limitation? It in turn calls sha256_update_swap which looks like it handles any size. Based on the spec: Quote:
It would be nice to make a PR for this but because of the optimization sensitive nature of this project, more thinking about exactly how to do that is needed - maintain optimization while allowing the buffer size to change without annoying recompilations. Oh and finally this is likely the issue - code needs to be generalized in: Quote:
Code:
token.len_min[1] = SALT_MIN; Code:
digest[0] = hex_to_u32 (hash_pos + 0); |
The First/Next change:... is a mistake I meant to say it is easiest to change:
Quote:
Code:
#define SALT_MAX 256 Either way I have no forward and back traced this issue - and I am guessing you changed SALT_MAX (it looks like for whatever reason PW_MAX is not used in 1450, not sure why). But you probably forgot to change the pw_t structure size. If either PW_MAX or SALT_MAX is increased about 256, the pw_t->i member needs its array size increased to max(SALT_MAX, PW_MAX)/sizeof(u32) which is currently correctly set to its corresponding 256/4=64 value. Probably why the comment "// do not try to simply change this, it will not work" is sitting right above those constants. Too bad that macro is no easy to integrate in the source due to that file being dependency free. Also please take note: Code:
#define RP_PASSWORD_SIZE 256 Quote:
|
Thanks chants,
the change I made was just this: Code:
#define SALT_MAX 8192 There are other calculations, looking in the chain of routines, which should be adjusted, but you risk doing only damage. The author should have put his hands in it, but I doubt he has the time and the will to do it. I'll do some more tests. |
@debugasm I would really hope to hear the results needed for the change. Especially try:
Quote:
Code:
typedef struct pw Quote:
Code:
#define RP_PASSWORD_SIZE 8192 The problem is the authors did not want to use dynamic memory for any size - since this would slow down the project significantly. And to fix a huge buffer size like this would negatively impact a lot of copy and other operations making them slower significantly. So how exactly to fix this is an interesting question. Instead they hardcoded the size values, knowing but not caring that there is correlation between them, and forcing custom compilation for now. I think the optimized code needs to be built on the fly which is a somewhat tricky thing to achieve though in the future I expect to see this become a regular thing. |
1 Attachment(s)
@chants with your change :
Code:
Hashfile 'message.txt' on line 1 (1d88f5...puNA+iZD2RbscVWiz1HusLS+dLyWwgQF): Token length exception Code:
\hashcat\include\common.h Code:
#define PW_MAX 8192 Code:
\hashcat\src\interface.c Code:
static bool parse_and_store_generic_salt (u8 *out_buf, int *out_len, const u8 *in_buf, const int in_len, MAYBE_UNUSED hashconfig_t *hashconfig) Code:
Hashfile 'message.txt' on line 1 (1d88f5...puNA+iZD2RbscVWiz1HusLS+dLyWwgQF): Salt-length exception The password is : 12345 |
The module has the failing check of PARSER_SALT_LENGTH ("Salt-length exception"):
Code:
const bool parse_rc = generic_salt_decode (hashconfig, salt_pos, salt_len, (u8 *) salt->salt_buf, (int *) &salt->salt_len); Quote:
Code:
u32 tmp_u32[(64 * 2) + 1] = { 0 }; I also agree that PW_MAX and SALT_MAX should be the same value. It looks like you have an old version of the source or did not change shared.c where it really needs to be changed as your error indicates this change you presume to have made was not yet made. |
I use the latest version available on the site:
https://hashcat.net/files/hashcat-5.1.0.tar.gz The code you mentioned does not exist in my "shared.c" ... :confused: Perhaps we are not synchronized with the same version. |
You are right - apparently they are restructuring the source significantly in the last 9 months... So forget the master branch on GitHub. I mean a ridiculous amount of redesign and refactoring has occurred. Better look at the 5.1 tagged branch here:
Quote:
Code:
int hashconfig_get_salt_max (hashcat_ctx_t *hashcat_ctx, const bool optimized_kernel) int hashconfig_get_pw_max (hashcat_ctx_t *hashcat_ctx, const bool optimized_kernel) has a lot of cases including the optimized_kernel most importantly also. But not needed for 1450 type. Without a doubt this change is incredibly close to working. |
1 Attachment(s)
I started again with this version:
Code:
https://github.com/hashcat/hashca/ Code:
// do not try to simply change this, it will not work Code:
static bool parse_and_store_generic_salt (u8 *out_buf, int *out_len, const u8 *in_buf, const int in_len, MAYBE_UNUSED hashconfig_t *hashconfig) Code:
int sha256s_parse_hash (u8 *input_buf, u32 input_len, hash_t *hash_buf, MAYBE_UNUSED hashconfig_t *hashconfig) Code:
hashcat (v5.1.0) starting... |
As long as the -O (optimized kernel) option is not specified which above it is not, then the _OLD values do not need to be changed as far as I can tell.
The fact that only the constants cannot be changed really indicates a lot of code smells with hard coded values many of which we already have documented. They should be changed to these constants or macros based on them. Since it just stops, did you change the pw_t structure and RP_PASSWORD_SIZE per the above post? It would seem like something might yet be crashing in the launched processes. But at least we have moved out of the parsing and initialization phase and into the processing phase... If there is a fully documented proof of changes here, then without a doubt this will get fixed in the main branch so just changing one constant and recompiling should become possible. But this project has been in a state of flux probably why hard coded constants are lurking all over the place. |
All times are GMT +8. The time now is 16:58. |
Powered by vBulletin® Version 3.8.8
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Always Your Best Friend: Aaron, JMI, ahmadmansoor, ZeNiX