version `GLIBC_2.14' not found (required by ./cudaHashcat64.bin)

[bios2bb]

hi everybody,

i am trying to run cudaHashcat which-1.21 on my The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali) Linux, but I get the following error. How should I fix this?

root@The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali):/usr/share/cudaHashcat# ./cudaHashcat64.bin
./cudaHashcat64.bin: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./cudaHashcat64.bin)
./cudaHashcat64.bin: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by ./cudaHashcat64.bin)

[atom]

The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali) needs to update to more recent glibc, this is really annoying

[bios2bb]

how can I do it?

[atom]

ask The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali) dev's to do it

[radix]

its not even The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali) really, its debian. I had to use experimental branch to get it working, but you are taking a risk that your entire machine breaks.

[rajak]

I'm running RHEL6 on one of my cracker boxes and have had similar issues. Actually first started happening with hashcat 64bit a while back where it wanted glibc 2.14. Now oclhashcat wants 2.15. I've been able to work around it thus far by compiling a separate install of glibc and preloading the libraries. From my understanding that isn't really a 100% safe way of doing it but it does appear to work for this use case. YMMV, no warranty, etc.

Steps I took to set it up this way:

1. Download and unpack glibc 2.15 (http://ftp.gnu.org/gnu/libc/glibc-2.15.tar.gz). cd into that dir.
   
2. Decide where you want to put this 2nd version of glibc, I used /opt/glibc. I create that directory as root and assign ownership of it to my build user.
   
   sudo mkdir /opt/glibc && sudo chown `whoami`:`groups | cut -f1 -d' '` /opt/glibc
   
3. To work around a bug in glibc-2.15, edit the 'Makeconfig' file in the glibc source dir and change this line:
   
   vardbdir = /var/db
   
   to
   
   vardbdir = <the-prefix-root-you-plan-to-use>/var/db
   
   so in my case
   
   vardbdir = /opt/glibc/var/db
   
   
4. mkdir build
   
5. cd build
   
6. NOTE: I run make install as my build user and not root to eliminate the possibility of something in the distribution's files being overwritten. This is important as glibc 2.15 tries to write to /var/db/ even with --prefix set (which is why we edited vardbdir above.) It is also just a safe practice when playing around with glibc.
   
   ../configure --prefix=/opt/glibc && make && make install
   
   
7. Test out oclHashcat using LD_PRELOAD to force the alternate glibc.
   
   LD_PRELOAD="/opt/glibc/lib/libc.so.6 /opt/glibc/lib/libdl.so.2" sudo /opt/hashcat/oclHashcat-1.21/oclHashcat64.bin -b
   

[rajak]

Meh, looks like this method does not work on oclHashcat as well as it did on hashcat. Seeing weirdness. Disregard.

[atom]

Can't you just pull out the required glibc files from the ubuntu package and then use LD_PRELOAD?

[debhead]

Can't you just pull out the required glibc files from the ubuntu package and then use LD_PRELOAD?

I'm having the same issue. Seems like it's not quite that simple.

Code:

$ LD_PRELOAD="/opt/libc-u/lib/x86_64-linux-gnu/libc.so.6" hashcat
Inconsistency detected by ld.so: dl-close.c: 743: _dl_close: Assertion `map->l_init_called' failed!

#for any command
$ LD_PRELOAD="/opt/libc-u/lib/x86_64-linux-gnu/libc.so.6" ls
Inconsistency detected by ld.so: dl-close.c: 743: _dl_close: Assertion `map->l_init_called' failed!

#Try loading all the shared libs except libOpenCL.so.1
$ LD_PRELOAD="/opt/libc-u/lib/x86_64-linux-gnu/libpthread.so.0 /opt/libc-u/lib/x86_64-linux-gnu/libdl.so.2 /opt/libc-u/lib/x86_64-linux-gnu/libc.so.6 /opt/libc-u/lib64/ld-linux-x86-64.so.2" hashcat
Segmentation fault

#Same for `ls`

I'm not sure if there is a simple way to kludge this. The best solution might be to upgrade to Debian Testing or switch to the supported Ubuntu version.

[Incisive]

For those of us trying to use Debian Wheezy, is there a simple way of satisfying the dependency? I don't get into testing packages often.