-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a FMT_FALSE companying FMT_NOT_EXACT #4483
Comments
After implementing this, we could have FMT_FALSE formats (like old DMG) default to keep trying (like they do now) but print a notice about |
We might (then) also want to refactor FMT_NOT_EXACT to something less confusing, such as FMT_HAS_COLLISIONS |
Formats with actual collsions, off the top of my head: CRC-32, oldoffice (RC4 key truncated to 40 bits), perhaps BFEgg (some weirdness with repeated patterns). I'm pretty sure there are more (but we could want to agree upon [and add a comment in |
Also, Hashcat has a "collider mode" for PDF versions 1.1-1.3, not sure if we support them or whether it applies to this context. Edit: It seems we do, |
I'm not convinced we need to change anything, but if we introduce an Speaking of collisions, there are also related issues with 7-bitness and truncation. We already have separate flags for those, but I imagine there could be weird cases where one would want to see all words in a list that match a hash despite of 7-bitness and/or truncation getting in the way. For example, when having related sets of passwords hashed as descrypt and bcrypt, first crack the descrypt and get all matches from RockYou, then test those against the bcrypt. So e.g. if both "nightwing" and "nightwind" match a descrypt hash, then actually detect and record both because the difference between them will matter when cracking the bcrypt. Edit: Related, should these flags prevent exclusion of previously cracked hashes found in I think in contests, team john-users occasionally inadvertently had cracks with 8-bit characters against descrypt, which later prevented the simpler 7-bit-only cracks against those and possibly resulted in fewer cracks of other hash types (some base words not automatically found because of the inadvertent 8-bit chars). However, a feature in |
For that very issue, the canonical solution is definitely to store 7-bit passwords in the pot file for 7-bit formats no matter what cracked it. Specifically, it could show like
while cracking, even though the pot entry would be I recall you opted against this at some point in time. And I agree it would be confusing once some clueless user runs
or
...or something like that. Another alternative is to simply store both. Not sure how current |
Another issue for contests (but only contests, me thinks) might be that we always store an 8-bit NT password as UTF-8, no matter how we cracked it. At least with current defaults IIRC. This applies to any format having |
There are two types of formats that can emit several candidates for one same hash: One example is CRC32, where each crack is correct so they're not false positives - any of them is correct. An example of the other type is DMG (at least in older code) which could emit actual false candidates - they will not work for opening that DMG file!
Current code has only the false positive formats setting FMT_NOT_EXACT (after a while of scope-creep from its original idea, because the two situations really should be separated). If you want more candidates from CRC32, just add --keep-guessing option.
We could want to add a FMT_FALSE flag that allows us to separate them, and describe this better. We'd replace all current FMT_NOT_EXACT with FMT_FALSE, and then use FMT_NOT_EXACT for CRC32 and the likes.
FMT_NOT_EXACT currently prints warnings like "Note: This format may emit false positives, so it will keep trying even after finding a possible candidate." or (using
--no-keep-guessing
) "Note: This format may emit false positives, but we will stop after finding first".Having both flags, those existing messages should be for FMT_FALSE instead, while the new FMT_NOT_EXACT would be more like "Note: This format has more than one correct password for each hash, (...)"
The text was updated successfully, but these errors were encountered: