hashcat / hashcat Goto Github PK

World's fastest and most advanced password recovery utility

Makefile 0.06% C 97.45% Batchfile 0.01% Shell 0.31% Perl 1.82% Python 0.22% C++ 0.07% Objective-C 0.07%

hashcat password cracking gpgpu opencl c hashes cuda

hashcat's Introduction

hashcat

hashcat is the world's fastest and most advanced password recovery utility, supporting five unique modes of attack for over 300 highly-optimized hashing algorithms. hashcat currently supports CPUs, GPUs, and other hardware accelerators on Linux, Windows, and macOS, and has facilities to help enable distributed password cracking.

License

hashcat is licensed under the MIT license. Refer to docs/license.txt for more information.

Installation

Download the latest release and unpack it in the desired location. Please remember to use 7z x when unpacking the archive from the command line to ensure full file paths remain intact.

Usage/Help

Please refer to the Hashcat Wiki and the output of --help for usage information and general help. A list of frequently asked questions may also be found here. The Hashcat Forum also contains a plethora of information. If you still think you need help by a real human come to Discord.

Building

Refer to BUILD.md for instructions on how to build hashcat from source.

Tests:

Travis	Coverity	GitHub Actions

Contributing

Contributions are welcome and encouraged, provided your code is of sufficient quality. Before submitting a pull request, please ensure your code adheres to the following requirements:

Licensed under MIT license, or dedicated to the public domain (BSD, GPL, etc. code is incompatible)
Adheres to gnu99 standard
Compiles cleanly with no warnings when compiled with -W -Wall -std=gnu99
Uses Allman-style code blocks & indentation
Uses 2-spaces as the indentation or a tab if it's required (for example: Makefiles)
Uses lower-case function and variable names
Avoids the use of ! and uses positive conditionals wherever possible (e.g., if (foo == 0) instead of if (!foo), and if (foo) instead of if (foo != 0))
Use code like array[index + 0] if you also need to do array[index + 1], to keep it aligned

You can use GNU Indent to help assist you with the style requirements:

indent -st -bad -bap -sc -bl -bli0 -ncdw -nce -cli0 -cbi0 -pcs -cs -npsl -bs -nbc -bls -blf -lp -i2 -ts2 -nut -l1024 -nbbo -fca -lc1024 -fc1

Your pull request should fully describe the functionality you are adding/removing or the problem you are solving. Regardless of whether your patch modifies one line or one thousand lines, you must describe what has prompted and/or motivated the change.

Solve only one problem in each pull request. If you're fixing a bug and adding a new feature, you need to make two separate pull requests. If you're fixing three bugs, you need to make three separate pull requests. If you're adding four new features, you need to make four separate pull requests. So on, and so forth.

If your patch fixes a bug, please be sure there is an issue open for the bug before submitting a pull request. If your patch aims to improve performance or optimize an algorithm, be sure to quantify your optimizations and document the trade-offs, and back up your claims with benchmarks and metrics.

In order to maintain the quality and integrity of the hashcat source tree, all pull requests must be reviewed and signed off by at least two board members before being merged. The project lead has the ultimate authority in deciding whether to accept or reject a pull request. Do not be discouraged if your pull request is rejected!

Happy Cracking!

hashcat's People

Contributors

Stargazers

Watchers

Forkers

thepleb magnumripper maksval isclever orbitusrobotics josephcopenhaver ancchaimongkon tuian comdet playwhyyza wenshao rajivraj nadeemhussain iusn dekryptor ken013194 kknet tzubal checkyourscreen yarlinware hebilicious m69w paleowoods projectarchives mayman99 samyoyo ivansalomon chankl linus-young doudousine dream1986 johnjohnsp1 thefighter cloudless tvonkeler xblackswan bsdemon sreejithcet windowsmani cerebralmischief tickez zhuyue1314 softdswyd aisling-kells melbshark lcjingdi jakeren yaoyi2008 duckybsd pluto1010 volt72 ggalancs meteoritt nimdas 01btc10 upxnoops andy737 ezhangle oere akpotter fsidnenko urandu cyberhorse208 security-geeks azmmat dardevelin tharanga-abeyseela saurabhshahpur secof bsmit126 fabiand93 azzhag connlan matrix shpedoikal dolfcao griha41 xxz stormholder ciklon-z merenon luccifer handong890 surven zhangf911 yuanfeng0905 olachan yourchanges wiona913 hj3938 zclfly passwind lockgit smther zdzhjx kamleshahre pekita1 kflavin ziv0chou tlapuste

hashcat's Issues

support to run oclHashcat within a cygwin shell

This feature request was originally reported on the (now obsolete and offline) trac ticketing system of hashcat.net.

Ticket details:
Original reporter (OP):	Mangix
Title:	Cygwin support?
Ticket number:	535
Date reported:	2014-11-17T02:53:20+01:00
Description:	currently, oclHashcat does not work properly with cygwin. All of the commands (s, q, p, etc.) do not get sent to the oclHashcat application. Instead, when using CTRL + C to exit it, the commands get sent separately. Would be useful to have it work correctly as cygwin supports openssh as a server(SSHing to your Windows box) as well as screen to manage oclHashcat.

Comments:
1.	philsmd	The main problem here is that the windows binaries of oclHashcat are meant to work great with cmd (the windows default command prompt). There are 2 features that oclHashcat implements within the status line: - user does not see the key that he presses (input will not be echoed) - user does not need to press ENTER after each key he presses for oclHashcat to recognize it exactly those 2 features are somehow platform-dependent (linux and windows treat this input differently). Since you now use cygwin on a windows machine, we indeed somehow need to have the linux-behaviour but the main problem is that the compiler for the windows binaries does not support the linux-behaviour (and as you can guess, devs do not use some sort of cygwin compiler at the moment). On the other hand, even if you are on cygwin, the remaining part needs to work like on a normal windows system (of course the underlying operating system is still windows after all). I can think of a compromise which would somehow work, but it unfortunately doesn't work great (and above all is doesn't work like the native windows and native linux status prompt of oclHashcat): - oclHashcat will detect if cygwin is running - if cygwin will be detected and the user inputs a key it will be echoed - if cygwin will be detected and the user inputs a key he needs to also press ENTER after each and every key The last 2 points of course aren't that great, but currently I cannot come up with an acceptable solution for this problem(s) (linux-behaviour-with-windows-compiler-targeted-for-windows-system). What do you think of my proposed solution?

support for NETLM hashes

This feature request was originally reported on the (now obsolete and offline) trac ticketing system of hashcat.net.

Ticket details:
Original reporter (OP):	Picch
Title:	Requesting LAN Manager (LM Hash) & NETLM Hash Addition
Ticket number:	471
Date reported:	2014-06-20T23:36:15+02:00
Description:	Hey Folks, I'm wondering about the feasibility of adding support for LM and NETLM hashes? I know their counterparts NT and NTLMv1/2 are already implemented but we've been running into cases while performing pentests where it would be more practical to attack the LM side of things given the weaknesses in the algorithm (and rainbow tables are going to be more trouble than their worth.) I have a sample LM hash that I've created and stole an NETLM hash example from ticket 98 [old trac ticketing system]: Password: HASHCAT2014 LabAccount:1012:299bd128c1101fd615c5627ce31416b2:d311c413a01dffad3ffd6f57bfe271d7::: In the hash above the data is as follows: <userAcct>:<uid>:<LM Hash>:<NT Hash>::: Password: PASSWORD1 test::LAB:76365E2D142B5612CD10E1B93D342334E8FD283ECD7B9170:8614B8A84404B1C0333C8875A22BC10690BBF6A7EDCF549D:1122334455667788 In the hash above the data is as follows: <userAcct>::<Domain>:<NETLM Hash>:<NETNTLMv1 hash>:<Challenge> I'm more than happy to provide any help that I can. Thanks! Garret Picchioni

Comments:
1.	philsmd	Note: You can crack the first (299bd128c1101fd615c5627ce31416b2) w/ -m 3000, output is: 299bd128c1101fd6:HASHCAT2014 Note2: You can crack the second one (d311c413a01dffad3ffd6f57bfe271d7) w/ -m 1000, output is: d311c413a01dffad3ffd6f57bfe271d7:hashcat2014
2.	Picch	Doh, didn't realize -m 3000 was there, apologies for that. NETLM would still be a nice addition though.
3.	atom	let's see if there [are] more request[s]. anyone else interes[s]ted in netlm please add a +1 here
4.	Izzet	+1

ERROR: cuMemsetD8() 1

Multiple users reported getting this error (both on windows/linux), with driver versions higher than the required one.

OS: Windows 7 64b
GPU : GTX Titan X
CPU : i5 2500k
Driver : 353.62
oclHashcat : 2.00

Command :
./cudaHashcat64.exe -m 100 ../hashcat-0.50/examples/A0.M100.hash example.dict

Output :

cudaHashcat v2.00 starting...

Device #1: GeForce GTX TITAN X, 12288MB, 1076Mhz, 24MCU

Hashes: 100 hashes; 100 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Rules: 1
Applicable Optimizers:
* Zero-Byte
* Precompute-Init
* Precompute-Merkle-Demgard
* Early-Skip
* Not-Salted
* Not-Iterated
* Single-Salt
* Scalar-Mode
* Raw-Hash
Watchdog: Temperature abort trigger set to 90c
Watchdog: Temperature retain trigger set to 80c
Device #1: Kernel z:\Hashcat\cudaHashcat-2.00/kernels/4318/m00100_a0.sm_52.64.cubin

Generated dictionary stats for example.dict: 1210228 bytes, 129988 words, 129988 keyspace
[...]
[s]tatus [p]ause [r]esume [b]ypass [q]uit =>

ERROR: cuMemsetD8() 1

support for openfire (jabber-server) hashes

This feature request was originally reported on the (now obsolete and offline) trac ticketing system of hashcat.net.

Ticket details:
Original reporter (OP):	crackall
Title:	openfire(jabber-server) hash
Ticket number:	449
Date reported:	2014-05-25T16:52:02+02:00
Description:	please add [~~function~~] bruteforce [support for] hash[es of] users in db openfire(jabber-server)

Comments:
1.	atom	please add more descriptions[:] like algorithm, example hashes, etc

longer salt length support for sha1($pass.$salt)

This feature request was originally reported on the (now obsolete and offline) trac ticketing system of hashcat.net.

Ticket details:
Original reporter (OP):	hithron
Title:	Increase the salt length.
Ticket number:	491
Date reported:	2014-08-11T16:14:21+02:00
Description:	Hello. I would like to see the salt length increase. At least on SHA1($pass.$salt). As i have a substantial amount of hashes that needs cracking. It's more and more common that i see developers face-rolling the keyboard to set a salt. A new limit on length to 35-40 on the most common algorithms? Hope you will take this under consideration.

Comments:
1.	atom	The current limit is 32 chars. Can you be a bit more specific which application uses longer salts? In that case, maybe we can make a specific mode for it. Because changing length in generic types will decrease performance on all algorithm that use gener[ic] types...
2.	hithron	Often its custom build web applications that i have seen this pattern in, but frameworks like Cakephp also starting to use a long string as salt. A mode would be great, to solve my problem but this seems to be a problem that comes up once in a while. But if a mode for SHA1($pass.$salt) would shut me up for a while. hashcat forum link 1, hashcat forum link 2

Reordering or files to help integration into linux distributions

Moved from hashcat forum: https://hashcat.net/forum/thread-4891.html

The problem with packaging hashcat right now, as dropdead and I were discussing, is that hashcat doesn't exactly adhere to the FHS. Basically the hashcat directory is a working directory, and that's rather contradictory to the FHS.
Ideally before we go down the road of Linux packaging, we would re-organize the file structure, such that binaries are in /usr/bin; kernels, rule files, etc. are in /usr/share/hashcat; and user files (pot, restore, induct) are in the user's home directory, e.g. ~/.hashcat).
Otherwise, we basically just have to stuff everything in /usr/share/hashcat and have the user run from that directory as root.

We discussed the new "layout", this is the final suggestion:

Have 3 types of folders:

Install folder
Profile folder
Session folder

Since this problem does not affect Windows, there will be no change. Everything will stay inside the Install folder as it is already.

For Linux it's different:

The Install folder is generally not so important as for Windows, it's usually /usr/bin and /usr/share
The Profile folder will be: ~/.hashcat
The Session folder will be: $profile/$session

We'll move files from the source tree to the following destinations (hopefully self-explaining) aka Install folder:

/usr/bin/*.bin
/usr/share/doc/oclHashcat/ (stuff from docs/* and example* files)
/usr/share/doc/oclHashcat/extra/*
/usr/share/oclHashcat/hashcat.hcstat
/usr/share/oclHashcat/charsets/*
/usr/share/oclHashcat/kernels/*
/usr/share/oclHashcat/masks/*
/usr/share/oclHashcat/rules/*

The Profile folder will have:

~/.hashcat/kernels/4098/*.kernel
~/.hashcat/hashcat.pot
~/.hashcat/hashcat.dictstat

The Session folder will have:

~/.hashcat/$session/hashcat.log
~/.hashcat/$session/hashcat.restore
~/.hashcat/$session/hashcat.restore.new
~/.hashcat/$session/outfiles/
~/.hashcat/$session/induct/

Use JIT compiler for DEScrypt

To increase DEScrypt cracking speed even more we should add a JIT compiler macro to set the salt of the hash which is to crack. This leads directly to the assumption that this technique makes only sense for single-hash cracking. Sure technically that's not correct but adding this to multi-hash, in the worst case, would create 4k of kernel code. The startup time would be horrible and the GPU memory to small. We could limit this feature to like 10 unique salts but that would make the code harder to understand. That's why i tend to implement this only for single hashes

Removing duplicate hashes... cudaHashcat!

hi bro,
I use cudaHashcat-v1.37 to recovery WEP,WPA. I get a problem, when i run command line:
cudaHashcat -m 2500 -a 0 myhash mydict
it worked and very strong. But when i run cudaHashcat like a service of windows, and print result to a file, i got some text like this:

cudaHashcat v1.37 starting...

Removing duplicate hashes...
Comparing hashes with potfile entries...
Structuring salts for cracking task...
Generating bitmap tables with 16 bits...

I google it, and I tried to use other versions (v 2.0, v 1.31), the result is not change. When I use hashcat(run like a service of windows) it worked.
My system: windows 8.1, Nvidia GeForce GTX 980, driver version: 9.18.13.4762, and cuda tool.
What 's the matter, and what should i do?
Thank you so much!

support for samsung full disk encryption (DEK)

This feature request was originally reported on the (now obsolete and offline) trac ticketing system of hashcat.net.

Ticket details:
Original reporter (OP):	dummys
Title:	Add Samsung full disk encryption cracking for DEK file
Ticket number:	575
Date reported:	2015-02-10T21:57:19+01:00
Description:	Hello folks, It could be cool [if you] implement the FDE algorithm from samsung. It's already done by Laszlo Toh for jtr (plugin) I think it's better to read the code, I'm to[o] bad to explain crypto. Here you have the explanation how to get the DEK -> forensicswiki - Android full disk encryption here the source: soonerorlater.hu - DerbyCon2013 Here is a test hash: f1da84cf0f8230b9a7bc16d4bced2220436d7cb750aaa3f26f41d32848cc630d1030 ae35b6e373b25c1c61dd3480078967342e47236820acdfcf413a100c2df4189e50 a04709ca5c901d42848a48627c password is test123

Comments:
1.	atom	Looks interes[s]ting. Is there still need for the algorithm? I mean because with newer Android versions [very much has changed and therefore it might be very different now]

support for SHA3 hashes of length 224

This feature request was originally reported on the (now obsolete and offline) trac ticketing system of hashcat.net.

Ticket details:
Original reporter (OP):	chick3nman
Title:	SHA-3 (keccak) Hashes of length 224 can not be loaded
Ticket number:	540
Date reported:	2014-11-24T07:44:55+01:00
Description:	The tested hash: e1dfad9bafeae6ef15f5bbb16cf4c26f09f5f1e7870581962fc84636 The [corresponding password for the] above hash is "hashcat" and has been hashed as Keccak-224. When loaded into oclHashcat 1.31, a line length exception is given and the hash is not cracked. Same error is given in v1.30. All other lengths load correctly(256, 384, 512) but 224 will not load.

Comments:
1.	atom	That's right, it's simply not supported. Which Application is using Keccak-224? If it's important enough we can think about an reimplementation to support it.

RFE: opensource OpenCL support

Now we have support OpenCL for:

CPU -> POCL
Intel GPU -> Beignet
AMD GPU -> mesa

Would be great to get opensource OpenCL support.

support for Kerberos 5 AP-REQ

This feature request was originally reported on the (now obsolete and offline) trac ticketing system of hashcat.net.

Ticket details:
Original reporter (OP):	initnull
Title:	Kerberos 5 AP-REQ
Ticket number:	524
Date reported:	2014-10-16T04:35:46+02:00
Description:	Hi, Could it be possible to add support for AP-Request Kerberos V5 hash? Currently, oclHashcat supports only the AS-Request Type 1 (https://hashcat.net/trac/ticket/137) As defined in: http://ftp.samba.org/pub/samba/specs/draft-brezak-win2k-krb-rc4-hmac-02.txt T = 1 for TS-ENC-TS in the AS-Request T = 2 for the Server Ticket in the AP-Request This T is used in the creation of K1 This particular type is used in the silver ticket attack. Basically it's pretty much the same with a twist on K1. The following code comes from https://github.com/nidem/kerberoast with some modifications to makes it easier to explain. word is the password plaintext = "Oksala123" key is ntlm of password in utf-16le format key = ntlmhash(word) def ntlmhash(s): hash = hashlib.new('md4', s.encode('utf-16le')).digest() return hash messagetype is 2 (AP-Request T) edata is binascii.unhexlify('3be794d602ed567c5fcd1b4cee7eb0653864faafef433c99b49c83fba4b6b33ff24312596347d7b9b1a30d36606987caef3e9198659fbbc08ddac9fb6b80ef167ccfebe09ec71973695675438a53ee1cdae29601f423dea0b223c1fccc05d841e7a02144e3a35b56c09609df000e74b165ae6eea7fc12b9919a54c0070dc8555b1c228b45089be24648b20dbef720ac71ef4a4bd3808a8489adae7fe6e3f2663e881ad57033e91583fdca5b2db96de53192a381654d83d489fb292826118564fa0ef7901fc25deda154978e5b15f23fb11038a46f2d478c31c11aa7f6e02a66de6ce3b5079fdf9cd76861d56bc70a4eb4c0ebbceac383fd5b0545070d9c7a33b9a45cbed4314f28cbaea345a1d834b46a05f67eb8114da7140b9365dec429967d20aa864853579b61a0f581ae9e7570c94351edc6b5e74585d2ce0640fe7a5704e6dad5431e975ab7800bd03a01226c77c12e01c647500a682ebc465df6cff7086a580e2abfc195fbf3516e53ac1ff9d99240226715e5885a5c57b0722d0c807fbe6df27d2a00b8f2e6e7e6263ea73fe10b4ce74bbc54eb620f89dc34d8348289d0bea42dfe10c0b821f7dba10455dfe3abe48f1ca5ac9ce45d4b3641749ed66fe5bfe7a57f267fd3d1841aae466214cc719cb58b4fe8ac2ed42c77cc905273ad7316efb5c119fcfc6cebf87149646e4c220527fd3a4c9a03de296f03eccee17f90dc2523805adf2f1c60afcfb575608362c0df24b15445eb08f1ea795f3e482a333a6a63b83d4def63cc2f6c9d10d46a05a82bc7b2d6524ef2560f50f902ecb0cb586376b2af4c16547d4b30ec2c239d6d625edf375d1067e8f8b057a865b88d63399cf136d3c2628f9fc695c298f99f1e61d3ed427c1434c9da4de069c24aa1ad3912744a0002b8f2596bc56a91a80970012ef5064c99af082e3494e2f6d37597cc62522503811c31446d6447d7286a1820f6bf99cc28166cbbac3174138ed1830aa6b312ad2b277f059635d52f6d3b20109d65d5b725f49a306ebc347df39628b443c3fcc1f564d31ddde0efaad4434500c6428575df45f84549a884b08c6aca82d9d06c903cca44c38516d15a43c3b0482f098351b783bed14a3a18c91efda24328453c65aad96da81557db1242650757f5ab95c23a1bcd87f496344f7225a5e36f9bc5e0f77f18891d8360acf805b3c71cf78ac6ac79c527ab29493c35c41409cb28d14c16db1ba2b6a775461a1defd783c1acbb295ba6bd31a7b4d4bb6991e2e9a1b6c740f3175cbdd3d9fb8c5bf250e39b3caf558d32d4e4ebbc6732486004657581f74d5af8293ec16baffe27ceb54cef29d2c21732b18ce297a4582fb5fcffe92ce4ff469b835075f1867c3ac140ffc44802634eb33543fe1cb887dec5d84718502a3bb0eecec2a0c154370555b5627420ee8fff83021a6a43a788747e6f43c48e605cddbf6dc31c8f8bc95f79f43d865677ecaeb71f738d496f797cd06975c1438f5575b6442980a1c31b5d5d0a31356fab640301a8089141b529e9fd01069') def decrypt(key, messagetype, edata): K1 = hmac.new(key, chr(messagetype) + "\x00\x00\x00", hashlib.md5).digest() K2 = K1 K3 = hmac.new(K1, edata[:16], hashlib.md5).digest() ddata = rc4crypt(K3, edata[16:]) checksum = hmac.new(K2, ddata, hashlib.md5).digest() if checksum == edata[:16]: return ddata[8:], ddata[:8] if the first ddata[8:] is not none, we have a successful decryption. Now, im pretty sure we can cut the checksum part as you did in the AS-REQ version, the decrypted data of this big chunk also starts with 20141015171431Z Im joining you the original file extracted from kerberos::list /export with mimikatz. it can be loaded with kerberoast (link in the begining). The password is Oksala123 Thanks.

Comments:
1.	atom	I agree there's some cracking speed optimization potential by not using the checksum [but by using] the 20141015171431Z timestamp [instead].
2.	twi1ight	wow, somebody already reported this type, it would be great in pentesting active directory
3.	monoxgas	Up one for including this type. Should be a really easy change from the AS-REQ type.

support for recovering ZIP (archive) passwords

This feature request was originally reported on the (now obsolete and offline) trac ticketing system of hashcat.net.

Ticket details:
Original reporter (OP):	minga
Title:	OCL support for .ZIP files
Ticket number:	161
Date reported:	2013-06-14T18:25:06+02:00
Description:	Auditors/Forensics people need to crack ZIP files. Would [be awesome to be able to] just [to] use OCL for this.

Comments:
1.	Rolf	ZipClassic (96 bit custom encryption used in the Old Days) should be supported too. It's not very GPU friendly, but the speeds are good (800M+ on GTX Titan using Passcovery).

Note: this ticket is not about .7z; recoverying passwords of .7z archives is already supported (-m 11600 = 7-Zip). The feature to add support for recovering RAR passwords was mentioned within a separate issue #68 (therefore please discuss here only about the different types of .zip files).

Cancel on next checkpoint

Attention: this issue is one of those imported from the old hashcat trac ticketing system.

OP: unix-ninja
Date of report: 2015-10-14
Original post:
"We should add a feature to the hashcat family of apps where we can press a hotkey to quit after the next "checkpoint" rather than immediately. Maybe (c) for cancel at checkpoint?"

This ticket was accepted by 'atom' on the trac ticketing system.
Thx

slight formatting problem in source code (tabs vs spaces)

The contribution/formatting rule:
5. Uses 2-character tabs and 2-character indentations

clearly says that we should prefer 2 spaces over 1 tab. Some code parts currently do not stick to this rule. I would suggest that we fix this as soon as possible.
Thx

support for punbb hashes

Hello, this is a follow up from forum thread: https://hashcat.net/forum/thread-4926-post-27675.html#pid27675

Would it be possible to add sha1($salt.sha1($pass)) into oclHashcat? There is already one (Redmine, -m 7600) but it uses 32 long salts.

Looking at the supported algos there is -m 3710 which is for MD5, so perhaps similar thing can be done with sha1 as well?

OpenCL/OSX support

Is this reasonable to ask? May be tied to #3

Reference: https://developer.apple.com/opencl/

support for (OpenSSL) pkcs and pem private keys

This feature request was originally reported on the (now obsolete and offline) trac ticketing system of hashcat.net.

Ticket details:
Original reporter (OP):	crackall
Title:	openssl keys
Ticket number:	447
Date reported:	2014-05-25T16:48:43+02:00
Description:	Please add bruteforce [support for] OpenSSL pkcs and pem format private key with passwd openssl genrsa [-out file.key] [-des

Comments:
1.	atom	please add more descriptions like algorithm, example hashes, etc

support for sha1(unicode($salt.$pass)) hashes

This feature request was originally reported on the (now obsolete and offline) trac ticketing system of hashcat.net.

Ticket details:
Original reporter (OP):	karl
Title:	Feature Request: SHA1(Unicode($salt.$password)) support in oclHashcat
Ticket number:	614
Date reported:	2015-04-16T20:17:49+02:00
Description:	I am requesting that the SHA1(Unicode($salt.$password)) hash type be considered for addition to oclHashcat. Specifically, this hash type is used to protect the McAfee Virus Scan Enterprise console for versions 8.x, which is implemented with a salt of "\x01\x0f\x0d\x33". Extraction of hashes can be done manually through the registry or by using the metasploit mcafee_vs_hashdump post exploitation module. A JtR dynamic format is available at the module developer's blog along with some additional details.

Comments:
1.	philsmd	Just a note: this should already work, with -m 140 = sha1($salt.unicode($pass)) and --hex-salt, like this: example: salt: $HEX[01000f000d003300] pass: a generate the sha1sum (sha1 ($salt . unicode ($pass)) echo -en "\x01\x00\x0f\x00\x0d\x00\x33\x00a\x00"

support for java KeyStore hashes

This feature request was originally reported on the (now obsolete and offline) trac ticketing system of hashcat.net.

Ticket details:
Original reporter (OP):	crackall
Title:	java keys store
Ticket number:	451
Date reported:	2014-05-25T16:54:10+02:00
Description:	please add [support to] brute java keys[:] oracle.com - keytool - Key and Certificate Management Tool

support for (ruby on rails) restful-authentication

This feature request was originally reported on the (now obsolete and offline) trac ticketing system of hashcat.net.

Ticket details:
Original reporter (OP):	joernchen
Title:	Support for restful-authentication hashing scheme
Ticket number:	223
Date reported:	2013-12-12T15:15:22+01:00
Description:	Hi, restful-authentication [0] is a quite popular Ruby on Rails extension which uses a rather flexible hashing scheme. Basically there is a side-wide and a[n] user-specific salt which both go into a configurable number of SHA1rounds (default 10) together with the password. Sample ruby code: require 'openssl' def secure_digest(*args) Digest::SHA1.hexdigest(args.flatten.join('--')) end def password_digest(password, salt, site_salt, rounds) digest = site_salt rounds.times do digest = secure_digest(digest, salt, password, site_salt) end digest end password = ARGV[0] salt = ARGV[1] site_salt = ARGV[2] rounds = ARGV[3] puts password_digest(password, salt, site_salt, rounds.to_i) Sample output: $ ruby build_hash.rb test test1 test2 10 36ca05ee9bc00c59f60096a6d41e336fa27a31d0 (here test is the password, test1 the salt, test2 the site salt, and 10 the number of rounds) I'd very much like to see this algorithm in [ocl]hashcat. Just let me know if this is doable. [0] Restful authentication - github

Comments:
1.	philsmd	It would be great if you could help me/us to understand some details: - are there some min/max salt/pass length rules - is there an already (de facto) way to recognize / write down all components needed for those hashes, e.g. hash:salt:site_salt:iterations , or any particular signature, also look here: hashcat example hashes. If some other cracker already supports those hashes, we should think about not introducing a different way to do enumerate those hashes (2 different signatures for the same thing is not so good, same holds for the whole line, including position of "site salt" and iterations) - I assume all this info is generally stored in a database where each field (salt,site_salt,hash,iter) has its own column, right? or is site_salt and iter a per-application value -> only salt + hash is in "database" ? thx
2.	joernchen	Hi, pass length is 6 to 40 chars, the salt is a SHA-1 hexdigest, so a string of length 40 with the pattern [0-9a-f] (generally no uppercase chars). I'm not aware of any cracker for this scheme. site_salt and iterations are stored in the applications configuration. hash und salt are stored per user in the database. The default number of iterations is 10. Hope that helps & sorry for the delay. joernchen
3.	atom	I'll add this sooner or later
4.	donnet1	+1 I would also like to see this algorithm in hashcat. Any idea when you will implement this atom?
5.	philsmd	We need an example "hash" that contains all informations (but most importantly w/ the correct salt lengths), e.g. of password "hashcat". Can you generate an example hash and collect all the info from configuration file and database and post it here in format: hash:salt:site_salt:plain As mentioned above the site_salt alone is already 40 chars in length. What about the (user defined) "salt" ? Is the length variable ? Is it randomly generated?
6.	donnet1	Philsmd, I was searching and stumbled upon this before I created a new trac ticket yesterday, however I just realized that I am looking for Devise which is very similar to restful-authentication however much more popular. At the time of writing, it has 10,736 stars on Github and 2,821 forks and wildly more used in software. After comparing both, the algorithm they use to hash the password is virtually the same. The only differences are: - Devise's site_salt is always empty, instead of a SHA1 in restful-authentication. - Devise's user_salt is generated differently using SecureRandom.urlsafe_base64(15).tr('lIO0', 'sxyz') which results in 20 character salts, instead of SHA1's in restful-authentication - Devise passes salt first to the secure_digest function inside the loop, then digest Here is the example hash you requested with restful-authentication: require 'digest/sha1' require 'erb' def secure_digest(_args) Digest::SHA1.hexdigest(args.flatten.join('--')) end # stretches is defeault to 10 DIGEST_STRECTCHES = 10 # site key (site salt) is generated like so, always a 40 char sha1 SITE_KEY = secure_digest(Time.now, (1..10).map{ rand.to_s }) puts 'Site Key: ' + SITE_KEY # user salt is geneated like so, same as site key always a 40 char sha1 USER_SALT = secure_digest(Time.now, (1..10).map{ rand.to_s }) puts 'User Salt: ' + USER_SALT def password_digest(password, salt) digest = SITE_KEY DIGEST_STRECTCHES.times do digest = secure_digest(digest, salt, password, SITE_KEY) end digest end puts 'Final Hash: ' + password_digest('hashcat', USER_SALT) hash:salt:site_salt:plain format: 9a48e120e736a4f9915da71d4b04634eb68df70f:0ea32eb8e813f797422f7a52305a2ce9c336008f:2097080b915d65d4c78a5d03f6ff095e96a3e615:hashcat Here is the same example but with Devise: require 'digest/sha1' require 'erb' require 'securerandom' def secure_digest(_args) Digest::SHA1.hexdigest(args.flatten.join('--')) end # stretches is defeault to 10 DIGEST_STRECTCHES = 10 # site key is empty SITE_KEY = '' # user salt is geneated like so USER_SALT = SecureRandom.urlsafe_base64(15).tr('lIO0', 'sxyz') puts 'User Salt: ' + USER_SALT def password_digest(password, salt) digest = SITE_KEY DIGEST_STRECTCHES.times do digest = secure_digest(salt, digest, password, SITE_KEY) end digest end puts 'Final Hash: ' + password_digest('hashcat', USER_SALT) hash:salt:plain format: cc4c5cbc2567bb729633c24bbcf9679241d4c234:hxE-93LEABQ9cJ4x-N6k:hashcat Should I make a separate trac ticket for Devise, or could you hit two birds with one stone? Let me know if you require anymore information about either. Thanks!
7.	philsmd	The main problem w/ restful-authentication is that the "string" we use in sha1 is at least 40 + 2 + 40 + 2 + x + 2 + 40, so at least 126 characters long... This will for sure imply that some optimizations (only a small number of SHA1 transforms etc) are not possible... The problem w/ the 'similarities' between restful-authentication and devise is that they seem to be very different indeed. While restful-authentication uses the "digest" always at the very beginning, devise has that digest in the middle somewhere and instead at the very beginning is the user salt. So it seems that we can't easily use one single GPU kernel for both hash types. Thx for the examples
8.	donnet1	philsmd, So with the output of your observations, does that leave us at these algorithms not being implemented into hashcat, or that it just won't be easy to implement?
9.	philsmd	yeah, we need 2 separate trac tickets (this for restful authentication and a new one for devise), then we need to check if: - restful authentication is still widely used and worth to implement - is there a minimum/maximum password length also for devise (this needs to be discussed in the new ticket, for this ticket, "restful authentication", it seems to be 6 - 40 chars).
10.	donnet1	Ok, I've created a new ticket for Devise [~~460 old hashcat trac ticketing system~~] [#77]. I would say that restful authentication is widely used, a couple big open source projects use it. As for the minimum/maximum password length for restful authentication, I just checked the code on github repo to confirm and it is 6-40 characters.

VCL support revisited

@jsteube, did you ever try out VCL using nvidia w/ OpenCL? I figure it would be easy now that you dropped CUDA. Do you have anything left of whatever VCL-specific code you had in there back then? Or perhaps there was no specific code, just an alternate linkage?

support to recover Woltlab Burning Board 4.x hashes

This feature request was originally reported on the (now obsolete and offline) trac ticketing system of hashcat.net.

Ticket details:
Original reporter (OP):	qwerasd12
Title:	Woltlab Burning Board 4.x
Ticket number:	404
Date reported:	2014-03-27T13:06:33+01:00
Description:	Woltlab Burning Board 3.x is already supported using mode 8400 but they changed the hashing in version 4.x to double bcrypt would be great to see this implemented in oclHashcat resource: woltlab.com - Information about the password hashing

Comments:
1.	atom	Can you please provide some example hashes/password pairs?
2.	qwerasd12	sure: $2a$08$Cq5HXldNxbD1NbBGA7Af2eXA3A/lq3UnGEFHl5DEevu2kTcpIxLVC == hashcat $2a$08$75HVxe4riDYxXk5HGRy7JeXr93v/6Uyw7sg0WQJuXp6sEl574CNqG == atom $2a$08$prNR9x4wwgJ6vjcqnv.nouTQebuai8lKhE6JSoDOLiZcaWiUPOVve == wotlab [to generate more hashes use the php file here: http://www.sendspace.com/file/cbhws5 php burningboard4.php password]

support for MS-CHAPv2

This feature request was originally reported on the (now obsolete and offline) trac ticketing system of hashcat.net.

Ticket details:
Original reporter (OP):	rezca
Title:	Add support for MS-CHAPv2 in oclHashcat
Ticket number:	613
Date reported:	2015-04-16T17:14:10+02:00
Description:	I know this has been suggested before in the forums, but I'd like to request support for recovering the MD4 hash from an MS-CHAPv2 challenge/response in oclHashcat. The problem is reduced to a single DES bruteforce by the good people at Cloud Cracker They're using dedicated hardware to accomplish this in less than a day, as the previous link details. Further it has been shown that it is cost effective to use CUDA vs dedicated hardware for DES key brute-forcing already in 2010. This [can] already be accomplished using openssl - github - heipei engine-cuda, however we know oclHashcat already has a DES implementation, and hashcat has nice features like pw-skip and pw-limit for space splitting. It's also unclear whether the openssl implementation would utilize all cores since it has very different goals. It would be great to allow researchers to do this using own resources (including EC2), at the very least to evaluate the cost-benefit of using a service like Cloud Cracker. Thanks!

Comments:
1.	atom	Once we have bitslice for DES it could be done with a single hd290x in ~ 100, or faster if you run multiple 290x in parallel which is supported with oclHashcat.

Half MD5 algorithm doesn't work in cudaHashcat on GTX 780 (error 999)

Good day!

I wanted to launch benchmark on my GTX 780, but it failed on Half MD5 algorithm with error "ERROR: cuStreamSynchronize() 999":

cudaHashcat v2.01 starting in benchmark-mode...

Device #1: GeForce GTX 780, 3072MB, 1006Mhz, 12MCU

Hashtype: Half MD5
Workload: 1024 loops, 256 accel



ERROR: cuStreamSynchronize() 999

This error is present both in 32-bit and 64-bit versions of cudaHashcat.

May be the value of loops (1024) is too large?
My OS is Win 7 x64, 16GB RAM.

Support for GPG/PGP private key

Hi,

A feature request that perhaps is easier to implement now when the cat has become open source?

I'd love to see support for attacking GPG/PGP (private keys) encryption within oclHashcat.
A wish is supporting AES256 and I am attaching two samples of the same password protected key.
Example one is the armoured private key and the second example is the same key converted by JtR with it's gpg2john tool.

2examplekeys.zip

Regards, Martin

-m 190 = sha1(LinkedIn) working but not listed under --help

this hash type is listed in the example hash wiki, it does work perfectly to crack hashes, there are special kernels for it... but still it is not listed under --help/usage.

I suggest that we add this hash type to the supported hash type list.
(or did we intend to remove it ? )

SL3 support

SL3 brought many problems and a noxious user base to this community in the past, but it doesn't seem to be the case anymore. Given that this technology is mostly obsolete and has become nearly a museum piece, it would be great to have it reimplemented.

support for the Mesa compiler/driver

This feature request was originally reported on the (now obsolete and offline) trac ticketing system of hashcat.net.

Ticket details:
Original reporter (OP):	Kucikuc24
Title:	OpenCL on Mesa
Ticket number:	229
Date reported:	2014-01-03T01:22:04+01:00
Description:	[Please] [a]dd support for OpenCL on Mesa aside with AMD Catalyst. Despite the fact Mesa's implementation of OpenCL currently does not support all the types of GPUs, we would be able to use oclHashcat with far more stable drivers on supported GPUs. This could also bring some performance improvements. For more information, please see the following link: archlinux - mesa wiki

Comments:
1.	atom	A few days ago I checked out that resource page how the progress is going. There's not much going on there. It seems to work for some ancient cards but for current state of the art hardware the status is set to work-in-progress. I will check again in a few months.
2.	atom	I'll not accept this as a form of "ok we will add it" more to have it in my list so that I keep an eye on it.
3.	Kucikuc24	May I have a question, atom ? Did you try an actual crypto code on mesa ? I mean, pyrit should work well. The tested card in the example on Arch Wiki is from Radeon HD 6700 serie but unfortunately, I do not have such a hardware right now so I could not test it.

support for Devise hashes

This feature request was originally reported on the (now obsolete and offline) trac ticketing system of hashcat.net.

Ticket details:
Original reporter (OP):	donnet1
Title:	Support for Devise hashing scheme
Ticket number:	460
Date reported:	2014-06-09T17:30:54+02:00
Description:	As discussed in previous ticket [~~223 from old trac ticketing system~~] #70, Devise is a popular authentication solution for Ruby On Rails. At the time of writing, it has 10,742 stars and 2,187 forks on Github - devise and is widely used in software. Here is an example in ruby on how to generate the hash: require 'digest/sha1' require 'erb' require 'securerandom' def secure_digest(*args) Digest::SHA1.hexdigest(args.flatten.join('--')) end # stretches is defeault to 10 DIGEST_STRECTCHES = 10 # site key is empty SITE_KEY = '' # user salt is geneated like so USER_SALT = SecureRandom.urlsafe_base64(15).tr('lIO0', 'sxyz') puts 'User Salt: ' + USER_SALT def password_digest(password, salt) digest = SITE_KEY DIGEST_STRECTCHES.times do digest = secure_digest(salt, digest, password, SITE_KEY) end digest end puts 'Final Hash: ' + password_digest('hashcat', USER_SALT) hash:salt:plain format: cc4c5cbc2567bb729633c24bbcf9679241d4c234:hxE-93LEABQ9cJ4x-N6k:hashcat Devise's user_salt is generated using SecureRandom.urlsafe_base64(15).tr('lIO0', 'sxyz') which results in 20 character salts - The minimum password length is allowed 6 characters. - The maximum password length is allowed 128 characters. Let me know if you have any questions.

support for OPENCART hashes

Hello.

Would it be possible to add sha1(salt.sha1(salt.sha1(pass))) into oclHashcat?
Hash algorithm for a very popular CMS (OPENCART)

sha1(salt.sha1(salt.sha1(pass)))

Hash:salt:pass
9c59d3071ee8a6486cf12d54d339f3b783ce2dde:0ccc3a77c:admin
d4d05b388a87e3055cc0ee109801cdca15e8d6d4:dbe8c88e5:taty
fabaff2487d3fc85b0fec32af618f5e8dc19b905:1dab633e0:admin

Download OpenCart
http://www.opencart.com/index.php?route=download/download

oclHashcat API

This is an amazing open source contribution. I wanted to start the discussion on whether creating an API would be beneficial. My thoughts are that there would probably be an interest in having an a well documented way to integrate hashcat into other systems. Feeding input/output to and from databases, connecting to distributed systems, and/or RESTful queries. I think this could also reduce the number of edits needed to the core code base, in the long run, in order to incorporate new/extended features.

Of course I'm willing to contribute effort to this matter should the community decide to pursue it.

support for recovering RAR (archive) passwords

This feature request was originally reported on the (now obsolete and offline) trac ticketing system of hashcat.net.

Ticket details:
Original reporter (OP):	minga
Title:	ocl support for RAR
Ticket number:	159
Date reported:	2013-06-14T18:22:56+02:00
Description:	In the business world, OCL support for encrypted RAR files would be amazing.

Comments:
1.	Rolf	I support this feature request, but WinRAR v5 is emerging, with a different encryption/hashing scheme. Also, some archives may use file name encryption, which again alters the scheme. All of this should be taken into consideration.
2.	Kucikuc24	Would be useful. +1
3.	Rolf	This will help : Archive format description and unrar sources.
4.	Rolf	Okay, WinRAR 5 was released.
5.	Rolf	I've talked to IvanG about WinRARv5 encryption, he said it's pretty straightforward: it uses PBKDF2/SHA256 for hash computation. He added it was made extra simple, so, once oclhc gets all the data extracted from the archive (the hash and precise iteration count), it can attack the hash itself without the need to decrypt any actual data. But this is only the latest version. Previous versions used variable (based on pw length) iteration count and other shenanigans. This may help

support for Inno Setup hashes

This feature request was originally reported on the (now obsolete and offline) trac ticketing system of hashcat.net.

Ticket details:
Original reporter (OP):	lucmc
Title:	hash type request: Inno Setup
Ticket number:	574
Date reported:	2015-02-10T09:22:33+01:00
Description:	Inno Setup is an installation utility that has the ability to encrypt files with RC4 and request password during installation. The password hash/salt can be easily extracted with a tool like: InnoUnpack. There are two versions of the algo: InnoSetup < 5.3.9: hash = md5('PasswordCheckHash', salt, 'PASSWORD') InnoSetup >= 5.3.9: hash = sha1('PasswordCheckHash', salt, 'PASSWORD') Both the PASSWORD and PasswordCheckHash are strings, however the salt is parsed in hex (from string). Example data: algo - md5 hash - 32cba66270ec6a9ecff50a28e1e01ab4 salt - e5d7af4f0e6ed7bf (hex) pass - aaa

Comments:
1.	philsmd	The algorithm here is just: -m 20 = md5 ($salt.$pass) or -m 120 = sha1 ($salt.$pass) since one can easily simplify that $salt = 'PasswordCheckHash', salt Therefore (and I tested it), you can simply crack these hashes like this: $ < hash cat 32cba66270ec6a9ecff50a28e1e01ab4:50617373776f7264436865636b48617368e5d7af4f0e6ed7bf $ ./oclHashcat64.bin -m 20 --hex-salt hash -a 3 aaa 32cba66270ec6a9ecff50a28e1e01ab4:50617373776f7264436865636b48617368e5d7af4f0e6ed7bf:aaa The only thing some users don't know is that one needs to use --hex-salt if (some part of) the salt should be converted from hex to binary. So basically, I converted the whole salt like this: $ echo -n PasswordCheckHash$(echo -en "\xe5\xd7\xaf\x4f\x0e\x6e\xd7\xbf")
2.	lucmc	Thanks for the fast response. Yes, both sha1/md5 are indeed working with the latest version I realize this is more of a user-friendly change, rather than actually new algo. As such its not something really necessary. However, here's my argument why it should be added: - Unless you start looking through the source you would never know that you have to prepend 'PasswordCheckHash', because the installer actually uses 'PasswordCheckHash' only for verification. The actual decryption just uses md5(salt, pass). - Easy-of-use: you can just input: hash:salt as strings without formatting or parsing

support for Gazelle cms hashes

This feature request was originally reported on the (now obsolete and offline) trac ticketing system of hashcat.net.

Ticket details:
Original reporter (OP):	grrgrr
Title:	hash type request: Gazelle cms
Ticket number:	579
Date reported:	2015-02-14T01:38:53+01:00
Description:	Gazelle cms < private torrent tracker site >[:] github - Gazelle line 372 sha1(md5($Secret).$Str.sha1($Secret).SITE_SALT); Secret is salt SITE_SALT [is defined] like this define('SITE_SALT','p]3ee}yuMMuu<&f1bl2QPglse?F3vg2f'); Default site wide salt, DO NOT LEAVE THIS BLANK/CHANGE AFTER LAUNCH! so [we] need [this:] sha1(md5(salt).pass.sha1(salt).site_salt) algorithm site_salt maybe using username username:passhash:salt (]U6C}yuMPuu<&G1BllQP2llT?Fkvgmc:e8b00900593151bbcf9119c332e503d1ce170d40:dgf26m98qtv9s1yubyq5eci5nm5nzwm9 plain is "jjapaget2" thx!!

Comments:
1.	atom	can you please tell us[e] the limits of the algorithm? That means, what is the minimum and maximum length of: - Password - Salt - Site-specific salt BTW: the subcall md5(salt) seems to be a bad idea as it can be precomputed. Bad design!

Hashcat compile but doesn't work on my Linux x64 with gcc 5.2

jvoisin@kaa 14:34 /opt/hashcat git pull                                                                                                              [master] git:hashcat
Already up-to-date.
jvoisin@kaa 14:34 /opt/hashcat make linux64                                                                                                          [master] git:hashcat
gcc -W -Wall -pipe -I include/ -O2 -s -fomit-frame-pointer -funroll-loops -Ideps/gmp/linux64/include -D__HC_x86_64__ -DLINUX -m64 -msse2 -c src/common.c -o obj/linux64/common.o
gcc -W -Wall -pipe -I include/ -O2 -s -fomit-frame-pointer -funroll-loops -Ideps/gmp/linux64/include -D__HC_x86_64__ -DLINUX -m64 -msse2 -c src/tsearch.c -o obj/linux64/tsearch.o
gcc -W -Wall -pipe -I include/ -O2 -s -fomit-frame-pointer -funroll-loops -Ideps/gmp/linux64/include -D__HC_x86_64__ -DLINUX -m64 -msse2 -c src/rp.c -o obj/linux64/rp.o
gcc -W -Wall -pipe -I include/ -O2 -s -fomit-frame-pointer -funroll-loops -Ideps/gmp/linux64/include -D__HC_x86_64__ -DLINUX -m64 -msse2 -c src/engine.c -o obj/linux64/engine.o
gcc -W -Wall -pipe -I include/ -O2 -s -fomit-frame-pointer -funroll-loops -Ideps/gmp/linux64/include -D__HC_x86_64__ -DLINUX -m64 -msse2 obj/linux64/*.o src/hashcat-cli.c -o obj/linux64/hashcat-cli64.bin  -Ldeps/gmp/linux64/lib -lm -lpthread -lgmp
cp obj/linux64/hashcat-cli64.bin .
jvoisin@kaa 14:34 /opt/hashcat ./hashcat-cli64.bin -b -m2500                                                                                         [master] git:hashcat
Initializing hashcat v2.00 with 4 threads and 32mb segment-size...

Device...........: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz
Instruction set..: x86_64
Number of threads: 4

jvoisin@kaa 14:34 /opt/hashcat gcc -v                                                                                                                [master] git:hashcat
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.2.1-22ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2) 
jvoisin@kaa 14:34 /opt/hashcat lscpu                                                                                                                 [master] git:hashcat
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    2
Core(s) per socket:    2
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 58
Model name:            Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz
Stepping:              9
CPU MHz:               3253.777
CPU max MHz:           3600.0000
CPU min MHz:           1200.0000
BogoMIPS:              5786.30
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              4096K
NUMA node0 CPU(s):     0-3

add prince attack to OCL/CUDA Hashcat

Would it be possible to merge PRINCE into OCL Hashcat? Currently I have noticed a bottleneck forming by having PRINCE run on the CPU and communicating with OCL Hashcat using a pipe.

nvml lib is not needed anymore (for compiling)

Since the GetRidOfCuda (GROC) branch did also implement the dynamic loading of the nvml library, we do not need to install the NVIDIA sdk anymore.
We should update the src/Makefile, tools/deps.sh and docs/BUILD.md to address this issue.
Thx

Build error in Archlinux with yaourt

4.2.5-1-ARCH x86_64 GNU/Linux
01:00.0 VGA compatible controller: NVIDIA Corporation GK107M [GeForce GT 750M](rev a1)
Installing hashcat with yaourt results in this error.
The source url in PKGBUILD file is just this repo.
Could there be some BUG in the build file?

==> Extracting sources...
  -> Creating working copy of oclHashcat git repo...
Switched to a new branch 'makepkg'
==> Starting pkgver()...
fatal: No annotated tags can describe '6e680aa31c9ff0a2705452801664ce6e3d0545e3'.
However, there were unannotated tags: try --tags.
==> Starting prepare()...
Matching Makefile ...
==> Removing existing $pkgdir/ directory...
==> Starting build()...
make: *** No rule to make target 'cudaHashcat64.bin'.  Stop.
==> ERROR: A failure occurred in build().
    Aborting...
==> ERROR: Makepkg was unable to build cudahashcat-git.

hashcat-deps (dependencies) should not be in /opt/ and therefore not require root permission

Currently the dependencies for oclHashcat (and for hashcat too) are all within the /opt/ directory (/opt/hashcat-deps to be exact).

I suggest that we should move the hashcat-deps directory directly into the root path of the github clone such that no root permissions are required and that the dependencies are local to the cloned repository.

Thx

support for QNX Neutrino 6.6.0 hashes

As documented here: https://moar.so/blog/qnx-password-hash-formats.html

Solar: "These are their own iterated SHA-512, SHA-256, or MD5" -- and DES is also mentioned as being used. As mentioned on john-users:

http://www.openwall.com/lists/john-users/2015/12/28/1

oclHashcat64.bin 'OPENCL_2.0' not found error

Hi,

I have Xubuntu 14.04.3 LTS setup with AMD HD 7950. I have installed AMD driver 15.11 (http://support.amd.com/en-us/download/desktop/previous/detail?os=Linux%20x86&rev=15.11). However, when I download and run oclHashcat 2.0 or 2.01, it errors as shown below.

./oclHashcat64.bin: /usr/lib/x86_64-linux-gnu/libOpenCL.so.1: version OPENCL_2.0' not found (required by ./oclHashcat64.bin)`

It works for 1.37 without any issues. Can you help identify the issue?.

Thanks

Reimplementing haschat/oclHashcat as Rumprun?

First, would it be possible for the developer to make a version that runs as a rumprun kernel for use on bare metal, or a hypervisor, and second, would it even make a difference regarding speed, etc, if it was? Just an idea.

support for RC4 known-plaintext attack

This feature request was originally reported on the (now obsolete and offline) trac ticketing system of hashcat.net.

Ticket details:
Original reporter (OP):	RC4_Support
Title:	RC4 known-plaintext attack support
Ticket number:	596
Date reported:	2015-03-03T08:36:01+01:00
Description:	[The i]dea [here] is [to implement a] kernel for [a] very generic RC4 plainttext attack. We already have some RC4 modules (pdf/office) so we can modify it. How it works? [The u]ser input[s] known bytes before, crypt bytes after (with same length). User set mask with his knowledge about key and that's all. Kernel functionality: - create RC4 initial state from the custom mask - decrypt specified user input with our state (result of step 1) - compare result bytes with specified user known-plaintext (if they match, log result, continue, there can be more keys) - repeat [The i]nput is in hex format. Maybe support for mask comparing? e.g Input: 11 22 33 44 Output 11 22 ?? 44 (?? mean[s] that it can be any char, 11 22 55 44 is [for instance a] good result)

support for cryptoloop images

This feature request was originally reported on the (now obsolete and offline) trac ticketing system of hashcat.net.

Ticket details:
Original reporter (OP):	b3nd3r
Title:	cryptoloop support
Ticket number:	230
Date reported:	2014-01-05T14:47:18+01:00
Description:	Hi, I've got an old cryptoloop-image and want to know, if there is any chance of getting support of these images in (ocl-)hashcat? Greetings, b3nd3r

Comments:
1.	atom	I'll add this sooner or later

--keyspace should not require valid OpenCL runtime environment

This feature request was originally reported on the (now obsolete and offline) trac ticketing system of hashcat.net.

Ticket details:
Original reporter (OP):	epixoip
Title:	`keyspace' flag should not require valid OpenCL runtime environment
Ticket number:	562
Date reported:	2015-01-26T20:39:39+01:00
Description:	I would like to propose that when using [the] `keyspace' flag, oclHashcat should simply calculate & print the keyspace, then exit. No OpenCL checks or device enumeration should be performed, as OpenCL runtime & devices are not required for this functionality.<br><br>The purpose for this request is three-fold:<br>\- Reduce the overall runtime of oclHashcat when --keyspace is used. This helps reduce overhead when calling oclHaschat programmatically in a distributed environment. Presently, running` oclHashcat --keyspace' takes about 3 seconds on a system with eight GPUs. Ideally this operation should complete in milliseconds. - Enable the keyspace flag to be used on systems without GPUs or an OpenCL runtime environment. - Eliminate the need for the standalone keyspace binary in hashcat-utils, which is now out of date due to the refactoring in 1.32

Comments:
1.	atom	That might be possible, but it's not so easy. For example, for oclHashcat you will need at least the libOpenCL.so/.dll with correct exports otherwise it won't start. You may can replace it with a dummy library. However, the standalone keyspace binary in hashcat-utils should be in sync with the current version. If not, we better patch it. Do you have an example [to] reproduce [it]?

support for sha1($salt.$pass.$username) hashes

This feature request was originally reported on the (now obsolete and offline) trac ticketing system of hashcat.net.

Ticket details:
Original reporter (OP):	digger
Title:	add new algoritm sha1($salt.$pass.$username)
Ticket number:	503
Date reported:	2014-09-13T14:41:08+02:00
Description:	Hi, could you add [this] algoritm[:] sha1($salt.$pass.$username)?

Comments:
1.	atom	Where is this used in?

Ticket details:
Original reporter (OP):	Hash-IT
Title:	Table-Lookup Attack
Ticket number:	26
Date reported:	2013-01-19T14:24:48+01:00
Description:	Please add this very useful attack to oclhashcat[~~plus~~]. I understand it can be piped from hashcat but in an effort to make things smaller and neater it would be fantastic to have this feature built in to oclhashcat[~~plus~~].

Comments:
1.	atom	I agree to that. This attack is extremly strong and would be even more strong[er] on GPU. But it['s] very incompatible to vector-datatypes and this is what makes GPU kernels [more] efficient. So I will accept that but I have currently no idea of how to implement it efficient[ly] so that there will be no massive performace loss. In that case it would give us no benfit to have it on GPU. Maybe there will never be [a reasonable] solution. For slow hashes like WPA or md5crypt it should be fast enough via pipe (as a workaround).

hashcat / hashcat Goto Github PK

hashcat's Introduction

hashcat

License

Installation

Usage/Help

Building

Contributing

Happy Cracking!

hashcat's People

Contributors

Stargazers

Watchers

Forkers

hashcat's Issues

Recommend Projects

Recommend Topics

Recommend Org

Jobs