• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Password cracking programs and stupid limits?

cyclone3d

Fully [H]
2FA
Joined
Aug 16, 2004
Messages
18,149
Note: this really is a programming issue / question

I've been trying to find a program that can crack the password of an old zip file that was downloaded years ago that may contain some BIOS editing tools.

The only thing I can see when opening this zip is another embedded gzip file and an empty text file that says that premium passwords are available after logging into devdownload.com

The problem is that that site is of course defunct.

I've gotten Hashcat to run but when using a mask with all alpha-numeric and special characters, it cannot even finish a run with a max of 6 characters.

Stupid thing is buggy and freezes up.

It also claims to support cracking passwords up to 256 characters in length but there is no way that would be possible unless maybe using a pre-generated word list.

I guess I could go that route but it seems really silly to have to do that.

With masking so it generates the passwords during run-time, it gives an error about an integer overflow when going above 12 or 13 characters and even with the max amount of characters without that error it will not run at all above 7 characters and then only runs a few seconds before crashing.

The reason for this error is that the mask is put into a single unsigned 64-bit integer. WHY? What am I missing here?

Why would an array of unsigned bytes (each byte will hold all 255 available characters) not be used? Then the password length would be able to go up way higher, even past the 256 character length provided the rest of the program would be limiting it at that point.

I highly doubt that somebody would make a password where you would need to enter ASCII codes so some of those codes could be limited out.
 
Not sure about the mask not being an array, could you point where in the code ?:
https://github.com/hashcat/hashcat/blob/master/include/types.h#L2604

Seem to be an array of bytes at quick glance:
char **masks;

Would it not be that the password lenght and masking make that there is more possible password you ask to try than the unsigned int 64 limit, so asking to possibly try more than 18,446,744,073,709,551,615 passwords ? Dictionary and/or more aggressive masking could be tried first.

testing all alpha_num +special character would rapidly explode the amount of possible.

It also claims to support cracking passwords up to 256 characters in length but there is no way that would be possible unless maybe using a pre-generated word list.

Or aggressive enough masking, a lot of time and compute, I suppose.
 
Last edited:
Definitely not asking it to do more than that many passwords.

From the documentation and what everybody is saying in the forums is that the mask is stored in a single unsigned 64-bit int.

The integer overflow when trying a larger mask also indicates that it is.

Maybe the mask list is in a char array and not the combined mask itself?

For a possible 7 characters long password, it claims about 19 minutes to complete using my 3080ti. That is with an all possible characters mask.

It should not be crashing either. Something is super screwy with the program.

--------

For masking, each possible character for each character in the password should only take 1 byte if including all possible ASCII values.

Put that in a char array and you have an available mask length of 2^64 -1.

The mask should not have to store all possible values and iterate through them... That is just silly.

You could also put the generated password in a char array as well and just iterate through it.

For a simple cracker, this would end up being slow but could theoretically crack passwords of up to
2^64 -1 characters in length provided you had enough RAM to do so.

Bit packing would reduce the amount of RAM needed by a decent amount as well as the actual possible values end at 126. Possibly the values below 32 would not be needed either.

A bit of bit shifting and on the fly index calculation and you are in business.

Of course the work could also be broken down into smaller workloads.
 
Definitely not asking it to do more than that many passwords.
just alphanumberical (upper-undercase, 0-9) would be what 62 characters, even without any special characters it grows incredibly fast. Back in my college computer class days, for computers of the time, even for only undercase letters and no numbers, brute forcing more than 5 chars passwords with zero strategy quickly became super long. I imagine now they get away with testing 1,000 password by minutes easily, but you could still be asking something to do humongous here.

62^62^62^62^62^62^62^62^62^62 = 839,299,365,868,340,224, depending on how many special characters you are allowing over that, 12-13 ? I can easily see that goes over the unsigned int limit number of possible password to be tested.

You can use this to have some idea:
https://www.omnicalculator.com/statistics/password-combination, 4 to 13 char, case sensitive, alpha-special + all special character, no known rule (minimum of numbers, special char, etc....) that would be:
44,071,824,612,352,140,000,000,000 + 466,145,535,693,846,430,000,000 + 4,919,235,320,721,367,000,000 + 51,747,588,589,332,760,000 + 541,907,701,932,187,140 + 5,638,526,145,757,440 + 58,124,770,600,832 + 591,002,298,432 + 5,885,106,656 + 56,693,520, possible password you are asking a simple home desktop computer to eventually run.

From my understanding the comments about the mask not fitting, it is not that the code used to register the users mask does not fit in its memory, is that the mask you give it in the command line define how many passwords to try, and it is telling you that it is way too much to realistically ever have an answer (and the code is not made to even run a loop that big). one trick to confirm this could be to try a much more restrictive mask, say to tell it every character must be an 0-9 number and see if it accepts the longer password mask has an argument.

From the documentation and what everybody is saying in the forums is that the mask is stored in a single unsigned 64-bit int.
But we have the code to directly look at.
 
Last edited:
Back
Top