OSTU - Sake Blok on Wireshark Capture File Manipulation (Part II)

3,744 views
3,647 views

Published on

Sake Blok, a Wireshark/Ethereal devotee since 1999, works as a Research & Development Engineer for ion-ip in the Netherlands (http://www.ionip.com) . His company provides solutions to customers who want to deliver their applications to users in a fast, secure, efficient and scalable manner. Sake\\\\\\\\\\\\\\\'s main focus is to take new products for a spin in their test environment, design custom solutions for customers and troubleshoot the problems customers might encounter while using ion-ip solutions. Two years ago (2006), Sake started to add the functionality he was missing to Wireshark. He also started to fix Wireshark-bugs that were reported on Bugzilla. This work on Wireshark resulted in an invitation from Gerald Combs to join the Wireshark Core Development Team in 2007.

Published in: Technology, Art & Photos
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
3,744
On SlideShare
0
From Embeds
0
Number of Embeds
423
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

OSTU - Sake Blok on Wireshark Capture File Manipulation (Part II)

  1. 1. Capture file manipulation Part II : changing packets September 2008
  2. 2. Welcome Back! <ul><li>Fourth episode of monthly series about using the wireshark CLI tools </li></ul><ul><li>Previous episodes can be found at: http://www.lovemytool.com/blog/sake_blok.html </li></ul>
  3. 3. This months topic <ul><li>In this fourth episode, I will show you how you can change the packets in a capture file </li></ul><ul><li>You will learn how to: </li></ul><ul><ul><li>change the snap length of packets </li></ul></ul><ul><ul><li>change the timestamps of packets </li></ul></ul><ul><ul><li>change the file type of a capture file </li></ul></ul>
  4. 4. Why change the snap length <ul><li>reduce storage size by removing data that is not involved in the analysis </li></ul><ul><li>remove &quot;sensitive&quot; data when forwarding network captures to third parties </li></ul>
  5. 5. Change the snap length of packets $ $ editcap -s 68 test.cap tmp.cap $ $ tshark -c1 -r test.cap -V | grep &quot;^Frame&quot; Frame 1 (110 bytes on wire, 110 bytes captured) $ tshark -c1 -r tmp.cap -V | grep &quot;^Frame&quot; Frame 1 (110 bytes on wire, 68 bytes captured) $ $ capinfos -csd test.cap File name: test.cap Number of packets: 27 File size: 5740 bytes Data size: 5284 bytes $ capinfos -csd tmp.cap File name: tmp.cap Number of packets: 27 File size: 2154 bytes Data size: 5284 bytes $
  6. 6. Useful snap length values <ul><li>ethernet layer => 14 bytes 7 6.263750 IntelCor_61:3a:ad -> ZyxelCom_fc:dd:76 IP [Packet size limited during capture] </li></ul><ul><li>up to IP header => 14+20 bytes 7 6.263750 192.168.1.46 -> 212.204.210.225 TCP [Packet size limited during capture] </li></ul><ul><li>up to TCP header => 14+20+20 bytes 7 6.263750 192.168.1.46 -> 212.204.210.225 TCP 22773 > http [PSH, ACK] Seq=1 Ack=1 Win=64000 Len=100 </li></ul><ul><li>with some app-data => 68 bytes 7 6.263750 192.168.1.46 -> 212.204.210.225 HTTP GET / HTTP/1.0 [Packet size limited during capture] </li></ul>
  7. 7. Why change timestamps of packets <ul><li>Why? Because sometimes you need to analyse multiple tracefiles that were made on different systems (with different &quot;unsynchronized&quot; clocks) </li></ul><ul><li>Before merging files from different systems </li></ul>
  8. 8. Change the time by how much? <ul><li>Tracefile A Tracefile B t a1 host A --> host B t b1 t a2 host A <-- host B t b2 </li></ul><ul><li>t b1 + correction b = t a1 + delay a<->b t b2 + correction b = t a2 - delay a<->b </li></ul><ul><li>t b1 + t b2 + 2*correction b = t a1 + t a2 </li></ul><ul><li>correction b = (t a1 -t b1 + t a2 -t b2 )/2 </li></ul>
  9. 9. Which packets to use for syncing time <ul><li>Look for request-response type packets like: </li></ul><ul><ul><li>ICMP: echo-request & echo-response </li></ul></ul><ul><ul><li>TCP: SYN & SYN/ACK </li></ul></ul><ul><ul><li>UDP: DNS-request & DNS-response </li></ul></ul><ul><li>TIP: Issue a ping between the two capturing hosts for syncing </li></ul>
  10. 10. Change the timestamps of packets $ tshark -ta -r client.cap &quot;tcp.flags.syn==1&quot; 1 22:31:59.246452 192.168.1.46 -> 192.168.1.20 TCP 43426 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=1 2 22:31:59.248515 192.168.1.20 -> 192.168.1.46 TCP http > 43426 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=7 $ tshark -ta -r server.cap &quot;tcp.flags.syn==1&quot; 1 22:31:49.548529 192.168.1.46 -> 192.168.1.20 TCP 43426 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=1 2 22:31:49.548556 192.168.1.20 -> 192.168.1.46 TCP http > 43426 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=7 $ correction = (59.246452-49.548529 + 59.248515-49.548556)/2 = 9.698941 $ editcap -t 9.698941 server.cap server-corrected.cap $ tshark -ta -r server-corrected.cap &quot;tcp.flags.syn==1&quot; 1 22:31:59.247470 192.168.1.46 -> 192.168.1.20 TCP 43426 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=1 2 22:31:59.247497 192.168.1.20 -> 192.168.1.46 TCP http > 43426 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=7 $
  11. 11. Change the file type of a capture file $ $ editcap -F netmon1 test.cap tmp.cap $ $ capinfos -tsd *cap File name: test.cap File type: Wireshark/tcpdump/... - libpcap File size: 5740 bytes Data size: 5284 bytes File name: tmp.cap File type: Microsoft NetMon 1.x File size: 5736 bytes Data size: 5284 bytes $
  12. 12. That's all folks! <ul><li>More info: </li></ul><ul><ul><li>see the manpages at: http://www.wireshark.org/docs/man-pages/ </li></ul></ul><ul><li>Next months episode: &quot;Control tsharks display format&quot; </li></ul><ul><li>e-mail: [email_address] </li></ul>
  13. 13. <ul><li>LoveMyTool.com Community for Network Monitoring & Management Tools </li></ul><ul><li>For additional educational videos on Open Source Network Tools, please visit: http://www.lovemytool.com/blog/ostu.html </li></ul>

×