0

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();
  • 2
    What's your question? If you send different data you'll receive different data. Also - not clear why you are adding binary data to a String in Java, you need a `byte[]` / `ByteArrayOutputStream`, not a String. – Erwin Bolwidt Oct 03 '19 at 22:43
  • 0A 0D are most likely \r \n, the one or 2 line / carriage returns, that differ from mac/windows/unix and more... and likely the programming languages, then. But does it make a difference in functionality? – B. Go Oct 03 '19 at 22:47
  • 3
    See https://stackoverflow.com/questions/1761051/difference-between-n-and-r and so many other web pages – B. Go Oct 03 '19 at 22:49
  • That's definitely a newline difference. – chrylis -cautiouslyoptimistic- Oct 03 '19 at 23:01
  • I thought it looked like CRLF too, but SMB PDUs don't contain "text" so there's no reason for line terminators. Here's the [negprot response](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-cifs/a4229e1a-8a4e-489a-a2eb-11b7f360e60c), assuming this is Ye Olde CIFS Dialectte of SMB (the OP does not say). –  Oct 04 '19 at 01:04
  • If the data is binary why are you using a `Reader`? You should be using an `InputStream`. – user207421 Oct 04 '19 at 02:27

1 Answers1

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.