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

Question

我正在发送一个SMB数据包，不同语言的响应不同，但只有一个字节的差异，它用python添加了0D

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)

爪哇语：

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

不是很好的答案。。。手工解析Python响应后，一些字段值看起来有点古怪。在PDU的逻辑端有一个字节。我的结论是额外的字节0d被错误地插入，但我不能说为什么

这是基于响应格式的SMB，而不是CIFS

SMB specification

Python响应

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

有些数字字段的数字完全不可信；用“？！”标记

Java响应

 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

这些字段在Java版本中更有意义

因此这里是我试图真正回答隐含的问题——Python版本是错误的；出于某种原因，它决定插入一个额外的字节。额外的字节是0D，可以解释为ASCII-CR，在恰好有值0A的字节之前，该值可以（错误地）解释为ASCII-LF。所以我们可能猜测这是一些错误的文本转换例程对非文本数据的咀嚼

==结语==

嗯，有一个更简单的方法来判断谁错了。SMB的长度应该是距消息第一个字0x55（85）。Java版本有85个字节，Python版本有86个字节。量化宽松