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 [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 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*
GIF image data, version 89a, 36 x 14
GIF image data, version 89a, 36 x 14
hacom:/root/tftpgrab-0.2# md5 192*
MD5 ( =
MD5 ( =

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!


Anonymous said…
Neat tool! Very useful for VOIP monitoring in particular.
wxs said…

Ported. I'll be submitting the PR tonight. :)
Anonymous said…
Not sure why you would be using unsecure protocols for file transfers? Practice what you preach.

What are you talking about? Do you think I am trying to catch my own activity when I conduct network security monitoring? Wake up.
Erik said…
I remembered reading this blogpost a while ago and decided to implement a TFTP parser into my open source application Network Miner packet analyzer.

So now there are two different applications available for extracting files sent over TFTP from PCAP files. NetworkMiner is however different from TFTPgrap in that it is written in C# and is intended for use with Windows. NetworkMiner also support "live" sniffing of network traffic through WinPcap. It also support extraction of files sent over HTTP and SMB.

Cool -- thanks!
Anonymous said…
Works great! Works as advertised thanks for raising awareness regarding this tool.
Unknown said…

How far can this be taken? Can I reconstruct any type of file captured by my sniffer and maintain the same hash? This argument came up today at work. Why can't we just magically reconstruct files from pcap?


Hi Chris,

It depends on how the pcap processing tool decides to handle any fragments, overlaps, etc. With a "clean" file it should work just fine... see the Matt Blaze paper mentioned at
red said…
This comment has been removed by a blog administrator.

Popular posts from this blog

Five Reasons I Want China Running Its Own Software

Cybersecurity Domains Mind Map

A Brief History of the Internet in Northern Virginia