[jcifs] Doesn't anyone have a SamOEMChangePassword capture?

[Tony Thompson]

I feel that I may be overstaying my welcome but, it seems like every time I make progress, I run into another wall.  I now have two traces that I can compare and they are definately different.

According to the cifsrap2.doc file, the things that I should be writing into the transaction request parameters section are:

- a 16 bit function number, in this case 214
- the parameter descriptor string "zsT"
- a null terminated ASCII string that represents the name of the user
- a word with a value of 532 representing the size of the data buffer

The problem is I think I also have to write in a data descriptor string "B516B16" even though it didn't say to in the document.  So, I have almost the same information that is in the Win98 pcap except the word with the value of 532.  The Win98 capture has a value of 814.

There are other things that are not the same in the traces that I don't know how to rectify.  In the Win98 pcap, it has a parameter count of 20.  In the jCIFS capture, it has a parameter count of 22.  There are several other things but some of them may dependent on each other (i.e. if I fix one thing the rest will correct themselves).

I am attaching two packet traces and my current source code.  Any input would be appreciated.

>>> "Michael B. Allen" <miallen at eskimo.com> 06/13/02 02:00PM >>>
On Thu, 13 Jun 2002 10:59:46 -0500
"Tony Thompson" <tony.thompson at stone-ware.com> wrote:

> From what I can tell by digging around in that code, I won't be able to
> do a straight comparison of the encrypted password data because the Samba
> code adds some random bytes into the new password buffer (I can probably
> do this too after everything works).  Does anyone have any suggestions?

Those  random  bytes  are  not  random.  They  can't be or the whole scheme
wouldn't  work.  That's  the  session  key  returned  in  SMB_COM_NEGOTIATE
response  and  also available from SmbTransport.client.sessionKey where you
can  get  the transport with SmbTransport.getSmbTransport() but you have to
use  the  transport before accessing the session key or the trransport will
not  have negotiated yet. But I don't recall seeing anything in the RAP doc
about  that. If it really is factoring in the sessionKey then that would be
pretty  important!  :~)  Regardless I've said it before and I say it again,
you  should  bother  doing  anything without a pcap. Now go find yourself a
Win98  machine,  tell  it  to  join the domain on your NT 4 server and then
change    your   password.   My   guess   is   that   will   show   you   a
SamOEMChangePassword.

You might try sending a message to the samba users mailing list asking very
nicely  for  someone  to  help you get a pcap. There are probably dozens of
users on there that could grab one in two shakes. 

Mike

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: jcifs_pass2_good.cap
Type: application/octet-stream
Size: 2794 bytes
Desc: not available
Url : http://lists.samba.org/archive/jcifs/attachments/20020614/0bdf68b1/jcifs_pass2_good.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 98_pass_good.cap
Type: application/octet-stream
Size: 4732 bytes
Desc: not available
Url : http://lists.samba.org/archive/jcifs/attachments/20020614/0bdf68b1/98_pass_good.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SamOemChangePassword.java
Type: application/octet-stream
Size: 6759 bytes
Desc: not available
Url : http://lists.samba.org/archive/jcifs/attachments/20020614/0bdf68b1/SamOemChangePassword.obj