base64 decode doesn't handle alternative alphabets

[cwalkatron]

base64 allows for alternate 62nd and 63rd characters. The LDAP {SSHA} scheme allows for this, but cudaHashcat-plus 0.14 doesn't seem to like. I get either a crash or the offending character in the hash is converted to an 'A'. For example:

foobar hashes to:

{SSHA}cdE9?c1HqhqfM7stWIbexLPqadQQUuVy

% ./cudaHashcat-plus64.bin -m 111 -d 2 ../ck3 ../foobar.dict
cudaHashcat-plus v0.14 by atom starting...

Hashes: 1 total, 1 unique salts, 1 unique digests
Bitmaps: 8 bits, 256 entries, 0x000000ff mask, 1024 bytes
Rules: 1
Workload: 128 loops, 80 accel
Watchdog: Temperature abort trigger set to 90c
Watchdog: Temperature retain trigger set to 80c
Device #1: skipped by user
Device #2: Quadro K5000, 4095MB, 705Mhz, 8MCU
Device #1: Kernel ./kernels/4318/m0110_a0.sm_30.64.ptx

Generated dictionary stats for ../foobar.dict: 7 bytes, 1 words, 1 keyspace

NOTE: autotuned --gpu-accel from 80 to 1


Session.Name...: cudaHashcat-plus
Status.........: Exhausted
Input.Mode.....: File (../foobar.dict)
Hash.Target....: {SSHA}cdE9Ac1HqhqfM7stWIbexLPqadQQUuVy
Hash.Type......: SSHA-1(Base64), nsldaps, Netscape LDAP SSHA
Time.Started...: Tue Jun 18 16:51:52 2013 (1 sec)
Time.Estimated.: 0 secs
Speed.GPU.#1...: 0/s
Recovered......: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.......: 1/1 (100.00%)
Rejected.......: 0/1 (0.00%)
HWMon.GPU.#1...: 0% Util, 35c Temp, 30% Fan

Started: Tue Jun 18 16:51:52 2013
Stopped: Tue Jun 18 16:51:53 2013

base64 definition: http://tools.ietf.org/html/rfc1521.html#section-5.2

[philsmd]

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)

[cwalkatron]

I'm sorry for posting hashes--I'll be more careful in the future.

I'm running LDAP and these hashes do indeed work with Netscape (Oracle) directory server. We use either 4- or 8-byte salts. The one I posted was 4-byte which requires no padding, but the 8-byte does (as you correctly pointed out). Since we're not using 20-byte salts as was stated in https://hashcat.net/trac/ticket/78, I think this is something different.

Normally, base64 will use A-Z, a-z, 0-9 and two additional characters since alpha/num only gets you to 62. Those are usually + and /, but can be any other printable. If you use a different two characters, hashcat does not behave correctly.