wireshark tcp 協議分析 z

雖然知道wireshark是抓包神器，只會大概大概用一下，還用一下下tcpdump，略懂一點BPF過濾器，也知道一點怎麼用 wirkshark過濾相關的報文，可是對於詳細的字段的含義，如何查看TCP的交互狀況還不是很是的瞭解。如今，簡單分析一下。PS：此次抓包的對象是 傳說中經過公安局多少多少級認證的本公司開發的交易系統，原本看到他的驗證碼傾斜的頗有規律，叫的斑斑點點也不是很密集。就想寫個小程序練習一下驗證碼識 別，但是我失望了，在wireshark裏面竟然沒有抓到任何報文，這個東西的驗證碼竟然是客戶端生成的，無語。因而，抓下登陸過程的報文，看看可否破 解，相關的TCP報文：crack.pcapng。關於報文分析，有一個很好的E文網站:packetlife。

  廢話少說，簡單在看看TCP的協議頭：
TCP協議頭
  這張圖片有點過時，保留位是6位，實際的狀況是，保留位的後2位已經被使用了。保留位的第5位是Congestion Window Reduced(CWR)，第6位是ECN-Echo(ECN)。TCP協議的其餘部分不說，先看看TCP協議的幾個不是很瞭解標誌是什麼意思。

• CWR(Congestion Window Reduced)
  簡單來講就是網絡不是很暢通了，通知對方減小阻塞窗口，發包速度發慢一點。

• ECN（ECN-Echo）
  ECN兩個做用，在TCP三次握手時代表TCP端是否支持ECN；在傳輸數據時，發送方是沒法知道網絡是否暢通的，可是通過重重的路由後，路由根據網絡的狀況能夠知道是否阻塞，路由會設置在IP層會設置的相應的標誌，即接收端發現了擁塞。CWR爲發送端縮小擁塞窗口標誌，用來通知發送端它已經收到了設置ECN標誌，應該減慢發包速度。關於ECN的詳細描述請參考：ECN

• URG(Urgent)
  這就是傳說中的帶外數據。由於TCP是沒有消息邊界的，假若有一種狀況，你已經發送了一些數據，可是此時，你要發送一些數據優先處理，就能夠設置這些標誌，同時若是設置了這個標誌，緊急指針也會設置爲相應的偏移。當接受方收到URG數據時，不緩存在接收窗口，直接往上傳給上層。具體的使用能夠參考TCP帶外數據。大致來講，就是，調用send和recv是要加上MSG_OOB參數。同時接收方要處理SIGURG信號。不過聽說這個帶外數據在實際上，用得不多。

• PSH（Push）
  簡單來講，就是告訴對方，我發這麼多數據了，你能夠處理了，不用緩衝在接收窗口了，直接交數據給上層吧。若是設置了SO_NODELAY選項，能夠強制設置這個標誌，若是設置了這個標誌，數據就不緩衝在發送窗口那裏，直接發送。

  TCP報文SYN ACK的計算以下：

A -> B SYN J ACK K LEN L B -> A SYN K ACK J+L LEN M A -> B SYN J+L ACK K+M 

  具體看下wireshark抓到的報文：

1. TCP3次握手的部分是幀1到幀3。
   創建鏈接

   • 第1幀，發送SYN J:
     A -> B seq = 0, win = 8192, len = 0, MSS = 1440, WS = 4, SACK_PERM = 1
     WS(Window Scale), 4表示左移動4位，原來窗口大小是16爲，如今是20爲，現代擴大了4倍，關於WS，這裏有比較詳細的描述tcp-windows-and-window-scaling。這裏比較疑惑的就是SACK_PERM這個TCP選項。SACK（Select ACKnowledgement）的目的就是當出現大量的報文丟失時增長恢復時間來用的，相似於累計ACK，就是說N多個ACK合成一個SACK。關於SACK，有兩個地方描述的比較詳細SelectiveAcknowledgements,TCP Selective Acknowledgment。
   • 第2幀，發送SYN K， ACK J+1:
     B -> A seq = 0, ACK = 1, Win = 14600, Len = 0, MSS = 1448, SACK_PERM = 1 WS = 128
     這些含義看第1幀，win = 14600, WS = 128，能夠看到這臺服務器的窗口很是大，WS也不少，網絡性能應該不錯的（事實也如此）。
   • 第3幀，發送SYN J+1， ACK K+1:
     A -> B seq = 1, ACK = 1, win = 66608, Len = 0
     這是創建TCP鏈接的第3次握手，這時win = 66608了，轉換爲2進制有17位比16位長，由於再第1幀第2幀的交互中已經交互了各類的TCP選項，因此此次的確認不帶有TCP選項。

   當這3次交互完成後，鏈接真正創建，只要服務端accept後，就能夠接收和發送數據了。

2. TCP數據傳輸
   普通數據傳輸
   截圖的是報文的第7幀，這個幀報文在此次抓的報文中相對有表明性點的。這個幀的報文設置了PSH標誌，並且是TCP分片傳輸的報文，由於此幀的報文是第6幀報文分片傳輸的，從ACK = 125能夠看出。傳輸數據的報文沒有什麼特別能夠說的：~

3. TCP終止鏈接的4次交換的部分是幀19到幀21（能夠發現，這裏的交互是有問題的）。
   終止鏈接

   • 第19幀，發送FIN J, ACK K:
     A -> B seq = 2559, ack = 2361, win = 65812, len = 0
     客戶端發起FIN主動關閉鏈接和上個報文的ACK（應該是接收完了數據，關閉SOCKET），客戶端最後應該會變成TIME_WAIT狀態。這是第一次交換。
   • 第20幀，發送FIN K， ACK J+1:
     B -> A seq = 2361, ack = 2560, Win = 26240, Len = 37
     這 次交換中，除了對客戶端的ACK外，同時發送FIN，但同時帶有37字節的數據，這37個數據不是咱們期待有的。能夠猜想一下，多是服務端裏面有37個 字節尚未發送，在收到FIN後，把緩存裏面的數據所有發送過去。服務端若是忘記的關閉鏈接，會變成CLOSE_WAIT狀態。這裏兩次的交換合併在一塊兒 了。
   • 第21幀，發送RST， ACK K+Len:
     A -> B seq = 2560, ACK = 2398, win = 0, Len = 0
     主動關閉一方收到FIN，迴應ACK。可是這裏卻有一個不是咱們期待的RST標誌。RST標誌代表往已經關閉鏈接發送數據，這是個錯誤。這是第四次交換。

   這裏的客戶端與服務端的交換是有問題的，在第20幀，收到FIN時，不該該再發送數據，這樣發送的數據頗有可能收到的就是RST。可是這並不必定是發送數據一方的問題，頗有多是客戶端尚未接受完數據就關閉鏈接了。但能夠確定的是，在客戶端或服務端某個地方確定存在BUG。

  這個就是某交易系統登陸的報文，報文涉及5次數據交互（請求-應答）。這有5次交換，第1，2次交換，極可能是交換RSA公鑰（猜的，由於報文 數據有OpenSSL標誌：~）。然然後面的還有3次數據交互，並非我期待的一次交互。難道還要同步其餘密鑰之類的？有空問下相關開發人員。若是是單純 破解報文的話，存在比較大的難度，可是若是是DOS攻擊的話，這應該是很是簡單的……