TFTPgrab

While I was teaching and speaking at conferences, I usually discussed research and coding projects with audience members. One of my requests involved writing a tool to reconstruct TFTP sessions. Because TFTP uses UDP, files transferred using TFTP cannot be rebuilt using Wireshark, TCPFlow, and similar tools. I was unaware of any tool that could rebuild TFTP transfers, despite the obvious benefit of being able to do so.

Today I was very surprised to receive an email from Gregory Fleischer, who directed me to his new tool TFTPgrab. He saw my ShmooCon talk earlier this year, heard my plea, and built a TFTP file transfer reconstruction tool! I downloaded and compiled it on FreeBSD 6.2 without incident, and here is I how I tested it.

I ensured a TFTP server was running on a FreeBSD system. I identified a small .gif to upload and download using TFTP.

richard@neely:~$ md5sum rss.gif 
01206e1a6dcfcb7bfb55f3d21700efd3  rss.gif
richard@neely:~$ tftp
tftp> binary
tftp> trace
Packet tracing on.
tftp> verbose
Verbose mode on.
tftp> connect hacom
tftp> put rss.gif
putting rss.gif to hacom.taosecurity.com:rss.gif [octet]
sent WRQ <file=rss.gif, mode=octet>
received ACK <block=0>
sent DATA <block=1, 451 bytes>
received ACK <block=1>
Sent 451 bytes in 0.0 seconds [inf bits/sec]

After the file was uploaded to the TFTP server I changed to /tmp, then downloaded the copy on the TFTP server.

richard@neely:~$ cd /tmp
richard@neely:/tmp$ tftp
tftp> verbose
Verbose mode on.
tftp> binary
mode set to octet
tftp> connect hacom
tftp> get rss.gif
getting from hacom.taosecurity.com:rss.gif to rss.gif [octet]
Received 451 bytes in 0.0 seconds [inf bits/sec]
tftp> quit
richard@neely:/tmp$ md5sum rss.gif 
01206e1a6dcfcb7bfb55f3d21700efd3  rss.gif

Notice the file I uploaded is exactly the same as the downloaded version, per the MD5 hashes.

The traffic looked like this.



I will have to be honest here and say that I expected to see everything happening over port 69 UDP. I didn't expect to see the server choose another port, but it's completely within spec and normal according to RFC 1350. Before commenting with a lecture on how TFTP works, please be aware that I read the relevant section of the RFC and understand transaction IDs and how ports are chosen.

I copied the trace to a system with TFTPgrab and let it process the trace.

hacom:/root/tftpgrab-0.2# ./tftpgrab -h
Usage: ./tftpgrab [OPTION]... [-r FILE] [EXPRESSION]
Reconstruct TFTP file contents from PCAP capture file.
With no FILE, or when FILE is -, read standard input.
   -r       PCAP file to read
   -f       overwrite existing files
   -c       print TFTP file contents to console
   -E       exclude TFTP filename when reconstructing
   -v       print verbose TFTP exchanges (repeat up to three times)
   -X       dump TFTP packet contents
   -B       check packets for bad checksums
   -d       specify debugging level
hacom:/root/tftpgrab-0.2# ./tftpgrab -r /tmp/tftpgrab.lpc
reading from file /tmp/tftpgrab.lpc, using datalink type EN10MB (Ethernet)
hacom:/root/tftpgrab-0.2# file 192*
192.168.002.101.32979-010.001.013.004.49324-rss.gif:
 GIF image data, version 89a, 36 x 14
192.168.002.101.32980-010.001.013.004.53366-rss.gif:
 GIF image data, version 89a, 36 x 14
hacom:/root/tftpgrab-0.2# md5 192*
MD5 (192.168.002.101.32979-010.001.013.004.49324-rss.gif) = 
 01206e1a6dcfcb7bfb55f3d21700efd3
MD5 (192.168.002.101.32980-010.001.013.004.53366-rss.gif) = 
 01206e1a6dcfcb7bfb55f3d21700efd3

As you can see, TFTPgrab pulled two files out of the trace and saved them to disk. They are identical to each other and to the original.

Thanks again to Gregory Fleischer for writing TFTPgrab!