base64 decode doesn't handle alternative alphabets
#2
Could you please explain this a little bit more? My questions:
1. Do you have a full example others (including devs) can test with? We need a *masked* hash:password pair... but remember only post HASHES if you are asked here (by moderators, devs, staff etc)
2. I am quite sure that hash mode 111 (nsldaps, SSHA-1(Base64), Netscape LDAP SSHA) is not using standard base64 , or at least the result of sha1 sum is at the very last step converted into a base64 form (together w/ salt) that has some specific properties (one of those is that the last 2 "output chars" are always "==" (padding))
3. are you sure you want to use hash mode 111? I am asking because it seems that you try to use a generic base64 string that has nothing to do with hash mode 111.

Furthermore, also your threads topic seems to indicate that you want to do something else, i.e. not use nsldaps at all.

If you just want to convert base64 to hex etc use one of this:
Code:
$ echo -n [BASE64_HERE] | base64 -d | xxd -p
$ echo -n [BASE64_HERE] | openssl base64 -d | xxd -p

Again, if you think there is a bug in oclHashcat we need a plaintext/*masked* hash pair we can test with.

Also, there seems to be a ticket open about nsldaps salt length in ocl (https://hashcat.net/trac/ticket/78 ), maybe you have a similar problem... but we need more details.

And don't forget: do NOT post hashes here!

UPDATE:
I just discovered that you have provided an example hash: plaintext foobar.
Since your hash is very short, it seems that there is a very short salt involved. Maybe this is really a problem of min/max salt length support (similar to ticket above)


Messages In This Thread
RE: base64 decode doesn't handle alternative alphabets - by philsmd - 06-19-2013, 10:45 AM