Keep Guessing

[C-Sto]

Use github issues only for bugs/feature requests - for discussions, general help and questions use the forum: https://hashtopolis.org Before you submit an issue please include the following information if you do not your issue will be closed.

• Your current Server version located at the bottom of any Hashtopolis webpage. Hashtopolis: 0.12.0+repository
• Current Client version same
• Your current Hashcat version 6.1.1
• The exact task command you are trying to run. N/A
• Debug output from the client by running "hashtopolis.exe -d" or with debug flag set on the python client. N/A

Describe your problem in as much detail as possible " It's broke " is not a description.

I'm currently generating partial collisions for a custom hash type manually, and would love to use hashtopolis to help manage the jobs. One of the key things that is allowing me to do this is to use the --keep-guessing flag in hashcat to continue finding preimages, despite the hash already being 'cracked'. Is this something that would be easy to implement?

[C-Sto]

after a quick look at the data model, this might require a substantial change:

CREATE TABLE `Hash` (
  `hashId`      INT(11)      NOT NULL,
  `hashlistId`  INT(11)      NOT NULL,
  `hash`        TEXT         NOT NULL,
  `salt`        VARCHAR(256) DEFAULT NULL,
  `plaintext`   VARCHAR(256) DEFAULT NULL,
  `timeCracked` BIGINT       DEFAULT NULL,
  `chunkId`     INT(11)      DEFAULT NULL,
  `isCracked`   TINYINT(4)   NOT NULL,
  `crackPos`    BIGINT       NOT NULL
) ENGINE = InnoDB;

Each hash in the hash table has a 1->1 mapping of plaintext to hashId. In reality (and in my specific case, more accurately), hashes can have many plaintexts. This would require a new table, and have the hash queries check the hash table, and the plaintext table. In most circumstances, it will be 1:1, so I'm not sure it's even worth the effort for my niche requirement 🙃

[C-Sto]

another minor update - I have worked around it with a mutilated local version. The changes are summarised as - rather than update the hash in the hashlist when a cracked hash is found, add a new hash to the hashlist with the associated plaintext and continue cracking. I suppose with a bit of work it could be added as a configuration for a specific hashlist

[s3inlc]

Indeed, you are completely right that the plaintexts are mapped 1:1 to the hashIds and that either a new table would be required or a workaround like you proposed. I definitely would oppose adding an extra table, as this most likely would hurt performance quite a bit for such an edge case. But your proposal of just adding the cracked hash as an additional hash in the table might work quite easily. I would have to check if there are not any issues arising with having two identical hashes in the table (one cracked and one uncracked). If you would like to do a PR with such a configurable addition I'm open to help you if needed.

[C-Sto]

I might take a swing at it if I find time - the usecase is so niche that I'm not sure many others will find it useful.

The version I have it working in locally is definitely not PR suitible, as it breaks a lot of other parts - will try to find time to tidy and make sure nothing else is too badly broken :)