[jcifs] SamOEMChangePassword works (sort of)

[Michael B. Allen]

On Mon, 17 Jun 2002 11:30:14 -0500
"Tony Thompson" <tony.thompson at stone-ware.com> wrote:

> >     abstract int writeParameterWordsWireFormat( byte[] dst, int dstIndex );
> >     abstract int writeBytesWireFormat( byte[] dst, int dstIndex );
> >     abstract int readParameterWordsWireFormat( byte[] buffer, 
> >                                         int bufferIndex )
> >                                         throws IOException;
> >     abstract int readBytesWireFormat( byte[] buffer, 
> >                                         int bufferIndex )
> >                                         throws IOException;
> > 
> > To  implement  any  SMB  message you just have to fill in these methods and
> > give that object to send or sendTransaction. The top level writeWriteFormat
> > method  will  call writeParameterWordsWireFormat and write the return value
> > of   that   into  the  ParameterCount  field.  It  will  do  the  same  for
> > writeBytesWireFormat  writing the return value from that into the DataCount
> > field.     Same     principle    for    readParameterWordsWireFormat    and
> > readBytesWireFormat.  In  other  words,  that  22 is being returned by your
> > writeParameterWordsWireFormat implementation. Have it return 20 instead. If
> > the  accounting  doesn't  add  up,  that might be a further clue as to what
> > constitutes a valid message and help to reverse engineer the precise format.
> 
> The methods that I am using are writeParametersWireFormat() and writeDataWireFormat() not writeParameterWordsWireFormat() and writeBytesWireFormat().  I also can't write 20 instead of 22 and get anything in a pcap that makes sense.  I am using a NG Sniffer instead of Ethereal to look at the traces (the decodes are much better) and I am still having a hard time figuring out where my issues are coming from.

Oh,  right. I forgot you're using Transactions. The same principle applies.
You  want  to return 20 instead of 22. If the pcap says the ByteCount is 20
then  I  don't  see how you can have 22 bytes of stuff in there. I've never
seen  that.  Check  your accounting again and take into consideration there
might  be a padding (although that could only add to the offset and not the
ByteCount I think). 

> One thing that I can't easily reconcile is the fact that the parameter descriptor string that I am sending is "zsT" but the only parameters that I send are:
> 
> - a null terminated string for the user ID (this is the "z" part)
> - a word with a value of 532 that represents the size of the data buffer (this is the "T" part)
> 
> Where did the "s" part go?  The pcap from the Win 98 machines doesn't have any extra bytes in there that would correspond to the "s" part either but, the word is not 532, it is 814.  The Sniffer reports that word as a 2 byte pad in the Win98 trace.

Donno. I'd have to look at the pcap again.

> There is a "parameter words" field in the transaction header that is partially wrong in the jCIFS trace as well.  I don't have a clue where any of that information came from but, it is wrong.

Partially  wrong  how?  Again, some of those fields are calculated based on
what you return from writeParametersWireFormat and writeDataWireFormat. 

Mike

-- 
http://www.eskimo.com/~miallen/c/jus.c