So you pretty much do the vchar by hand there. Would this do the trick? vchar 8 16 | spec 2-* 1 1 n
On 8 May 2015 at 17:07, Martha McConaghy <[email protected]> wrote: > 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 >
