Thanks, John, for the advice. I finally did solve my problem. Turned out
I was making it more complicated than it needed to be. The problem was
not the UFT code, but the "endian". NTLM hash requires the input to be little
endian. After a colleague and I dug through all the "code talk" documentation
and tweaking bits here and there, we stumbled onto the answer. (I haven't
done this much bit manipulation since my Assembler class 30 years ago...sigh..
I even got out my old "green card" for support. Actually, the yellow
"System/370 Reference Summary" yellow book.)
Just in case any one is interested, here's how we solved it.
The translation from EBCDIC to ASCII was OK. For the string, "abc", that
gives me x616263. The 'vchar 8 16' gave me x006100620063. However, since
NTLM wants the input to be "little endian", that input gave me the wrong
response. However, putting the x00 at the end of each byte, did the trick,
x610062006300. The code looks like the following:
'PIPE var String1|' ,
'xlate from 37 to 819|' ,
'fblock 1|' ,
'spec 1 1 x00 n|' ,
'join *|' ,
'strip|' ,
'rexx md4|' ,
'cons'
The NTLM hash of 'abc' comes out as:
E0FBA38268D0EC66EF1CB452D5885E53
which matches the online NTLM hash generators on I have found.
I have to admit, getting back to the good old basics of messing with bits and
bytes was fun. A nice break from all the admin stuff we end up doing now.
Martha
