python 和 java 之间的套接字响应不同

Question

I am sending a SMB packet, the response is different between languages, but only one byte of difference, it adds 0D with python

00 00 00 55 FF 53 4D 42 72 00 00 00 00 98 01 28 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2F 4B 00 00 C5 5E 11 03 00 03 0D 0A 00 01 00 04 11 00 00 00 00 01 00 00 00 00 00 FD E3 00 80 12 E5 E0 59 36 7A D5 01 88 FF 00 10 00 B0 44 B3 6C 20 08 11 44 A9 84 31 87 23 FC C7 45

Python:

buffersize = 1024
timeout = 5.0
client = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
client.settimeout(timeout)
client.connect((ip, port)) 
client.send(negotiate_proto_request())
tcp_response = client.recv(buffersize)

Java:

Socket s = new Socket(ip, port);
OutputStream out = s.getOutputStream();
out.write(negotiate_proto_request().getBytes());
out.flush();

InputStream input = s.getInputStream();
InputStreamReader reader = new InputStreamReader(input);
tcp_response = "";
int i = 0;
tcp_response += (char) reader.read();
tcp_response += (char) reader.read();
tcp_response += (char) reader.read();
int len = reader.read();
tcp_response += (char) len;
while (i < len) {
    tcp_response += (char) reader.read();
    i++;
}
out.close();
s.close();

Answer 1

Not quite an answer... having hand-parsed the Python response, some of the field values look a little wacky. And there's a byte past the logical end of the PDU. I conclude that extra byte 0d was inserted erroneously, but I can't say why.

This is SMB, not CIFS, based on the response format.

SMB specification

Python response

00 00 00 55 

header 

FF 53 4D 42       protocol identifier
72                negprot
   00 00 00  
00                status
   98             flags  (response + others)
      01 28       flags2
00 00             pid high
      00 00 
00 00 00 00 
00 00             security features
      00 00       rsvd
00 00             tid
      2F 4B       pid low
00 00             uid
      C5 5E       mid

params

11                word count (17)
   03 00          dialect index 3
         03       security mode
0D 0A             max mpx (2573 ?!)
      00 01       max vcs (256 ?!)
00 04 11 00       max buff size (1,115,136‬ ?!)
00 00 00 01       max raw size (1 ?!)
00 00 00 00       session key
00 FD E3 00       capabilities
80 12 E5 E0  
59 36 7A D5       server time
01 88             server tz (34817 ?!)
      FF          challenge len (255 ?!)

data
      00 
10                byte count
   00 B0 44 
B3 6C 20 08 
11 44 A9 84 
31 87 23 FC 
C7                server guid

   45             fell off the end
                  or maybe I have forgotten
                  the SMB alignment rules

Some of the numeric fields have completely implausible numbers; marked them with '?.'.

Java response

 00 00 00 55

header (same as before)

 FF 53 4D 42
 72 00 00 00
 00 98 01 28
 00 00 00 00
 00 00 00 00
 00 00 00 00
 00 00 2F 4B
 00 00 C5 5E

params 

 11              word count (17)
    03 00        dialect index 3
          03     security mode
 0A 00           max mpx (10)
       01 00     max vcs (1)
 04 11 00 00     max buffer (4356)
 00 00 01 00     max raw (64k)
 00 00 00 00     session key
 FD E3 00 80     capabilities
 12 E5 E0 59     server time
 36 7A D5 01  
 88 FF           server tz (-120)
       00        challenge len

data 
          10    
 00              byte count (16)
    B0 44 B3
 6C 20 08 11
 44 A9 84 31
 87 23 FC C7 
 45

The fields make much more sense in the Java version.

So here is my attempt to actually answer the implied question - the Python version is wrong; it has for some reason decided to insert an extra byte. The extra byte is 0D, which can be interpreted as ASCII CR, and is before a byte that happens to have the value 0A, which can be (mis)interpreted as ASCII LF. So we might guess that this is some mistaken text-conversion routine chomping on non-text data.

== Epilogue ==

Duh, there's an easier way to tell which one's wrong. The length of the SMB is supposed to be 0x55 (85) from the first word of the message. There are 85 bytes in the Java version, 86 bytes in the Python version. QED.