[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#856932: hashcat dependency problem



[ ccing Petter for his input on isenkram at the end ]

Hello,

On Mon, 06 Mar 2017, Philipp wrote:
> Firstly, I just want to let you know that I already tried to contact some
> Kali/Debian developers privately (via mail, for instance the dev rhertzog
> which seems to be active and somehow related to this package) about this

Yeah, sorry for this I have been busy with other things. I already
replied privately to Philipp so I will paste my answer here and add some
more comments at the end for things that were not included in my private
mail.

On Wed, 22 Feb 2017, Philipp Schmidt wrote:
> The users most of the time get one of these error messages:
> "clGetDeviceIDs(): CL_DEVICE_NOT_FOUND", "clBuildProgram():
> CL_BUILD_PROGRAM_FAILURE" etc
> ... even though the hardware is perfectly supported by both hashcat and the
> vendor's driver.

Yes, we get many such reports ourselves too:
https://bugs.kali.org/view.php?id=3432
https://bugs.kali.org/view.php?id=3867
https://bugs.kali.org/view.php?id=3835

> This is, for what I've seen until now, also the main cause of most of the
> problems the user experience, i.e. that the dependencies of the "hashcat"
> package incorrectly say that hashcat depends on the Mesa driver.

We are working to fix this... but it's not helpful if they don't
get any other driver at all.

https://anonscm.debian.org/cgit/pkg-security/hashcat.git/commit/?id=e80372b90140299eb1607eb6c299bcd65a5bf848


> I decided to download the current stabel ISO of Kali from
> https://www.kali.org/downloads/ and started a completely fresh install (on
> physical disk, not virtual machine, just to be sure). My setup for this
> test is 1 x NVidia GTX 980ti.

Please test with the latest weekly image if you want to help us:
http://cdimage.kali.org/kali-weekly/
http://cdimage.kali.org/kali-weekly/kali-linux-2017-W10-amd64.iso

> for me. This is not related to hashcat, but it could get the unexperienced
> users quite frustrated and he might give up already. My
> /etc/apt/sources.list was just containing references to the "CD"
> repositories, I had to replace the /etc/apt/sources.list with this:
> # cat /etc/apt/sources.list
> deb http://http.kali.org/kali kali-rolling main non-free contrib
> 
> This might have something to do with the networking settings (I choose to
> configure the network after installing the OS), but this shows how

Yes this is because you had no network configured during setup.

> If it is the case that you can't ship more kernel headers than the one for
> 4.9.0-kali2-amd64, than you need to fix all the dependencies to point to
> kernel image 4.9.0-kali2-amd64, otherwise installation of the nvidia-driver
> silently fails etc etc etc.

This is not normal. If you install nvidia-kernel-dkms to get your nvidia
kernel modules, you get a dependency on "dkms" which depends on
linux-headers-amd64 and this package always depends on the corresponding
package of the latest kernel version (aka linux-headers-4.8.0-kali2-amd64
currently).

So if your system is up-to-date (apt update && apt full-upgrade), you have
everything required for the build to succeed automatically.


> I also tested a newer version of Kali (weekly build #8 of 2017) and
> experienced almost exactly the same problems.

Well, you had no luck as we made a kernel update in the week where you
tried.

> # apt-get install nvidia-driver
> # apt-get install nvidia-opencl-icd

Note that just doing "apt install nvidia-opencl-icd" automatically pulls
the required parts of the nvidia-driver (aka nvidia-kernel-dkms). Does
the installation nvidia-driver pulls other stuffs that are needed by
hashcat?

> The same might be true for AMD GPUs (with firmware-amd-graphics?).
> I did not yet test how easy/difficult it is to get kali to run hashcat with
> AMD GPUs (proprietary driver) since I first wanted to know how much you, or
> kali/debian in general, are interested to coordinate and find a good
> solution for the NVidia problem (first).

I am very interested and I can fix the packaging directly in Debian as
part of the Debian Security Tools Packaging Team.

> Additionally, since both NVidia hardware and drivers currently are the
> better choice if it comes to hash cracking with hashcat (whenever we
> compare NVidia to AMD), the focus of hashcat is on NVidia graphic cards.
> This is also why most of the hashcat's users have new NVidia cards (gtx
> 980, gtx 980ti, gtx 1080 etc) and it would be great if hashcat just works
> out-of-the-box (or at least with very little need for the user to mess
> around the whole system to get it running).

But nvidia drivers are non-free and thus not part of Debian. So hashcat
cannot be tailored for this use-case, at least not in Debian.

> What do you think can be done to resolve these difficulties a kali user
> faces when he tries to "just run hashcat"? Can we somehow improve the
> dependencies and overall reach an user-friendlier install process? It's
> good that hashcat is preinstalled, but it is currently not working at all
> by-default, because of this incorrect mesa-dependencies etc.

I see two ways forward:
- switch to have pocl by default instead of mesa
- provide hashcat-nvidia package that pulls everything required for nvidia
  support

--- coming back to parts which are specific to the bug report

> I am sure there might be some very clever/intuitive solutions to this problem.
> Maybe with a wrapper, first-run script or something similar, such that hashcat
> can still be pre-installed. I'm not sure what the best option is because I'm not
> totally familiar how something like this is normally handled (but I guess there
> might exist a lot of projects/packages out there that depend on alternative
> packages and a package selection mechanism that depends heavily on the hardware
> of the user).

The need to install specific package depending on the hardware is a hard
problem. In Debian I know of the isenkram package that tries to guide
the user to install the needed packages for his hardware but I don't
know if we can extend its data to suggest new packages to install
based on what software is installed.

And I also don't think that the required package installation can be
automated. I believe there is some support for this in the installer
but I don't know currently how it works.

> Hashcat developers, including but not limited to atom (the main author), epixoip
> (a very active member/contributor/moderator which seems to grasp packages/debs
> dependencies and how one should create packages much better than me. Yeah, he
> even builds/maintains his own repositories/packages) an myself (philsmd), are
> happy to discuss a possible solution for this issue (preferably on #hashcat IRC
> - freenode - given that emails seem to not always reach the target or do not get
> answered).

I'm "buxy" on IRC (Freenode and OFTC). I'm happy to chat about this but I
prefer even more to have a log of the conversation so I'm happy to
continue this over email.

Cheers,
-- 
Rapha?l Hertzog ? Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/



Reply to: