Take this executable submitted on 05/13/09 as an example:
Sections ( UPX0 UPX1 UPX2 )
File: MS-DOS executable PE for MS Windows (GUI) Intel 80386 32-bit, UPX compressed
Strings:UNPACKED Us%se%sla/4.0 (compatible; MSIE 7.0; %s; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Strings:UNPACKED reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable /t REG_DWORD /d 00 /f
Strings:UNPACKED reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable /t REG_DWORD /d 00 /f
Strings:UNPACKED Software\Microsoft\Windows\CurrentVersion\Internet Settings
Size: 14848 bytes,
UPX isn't particularly impressive because "upx -d" works fine most of the time, but this method gets a lot of other packed files too. It uses clamscan (from clamav.net) with --leave-temps, then it looks for URLs, Registry keys, domain names, and anything else interesting it could find in the strings. If it finds the same string in the original binary, then it does not display UNPACKED before outputting it. In this way, the analyst can see if it was really hidden or available in the original strings output.
The --leave-temps method is not perfect, but it has helped me on a number of occassions when I was in a hurry to evaluate the likelihood that a binary was malicious or find the purpose of an unknown binary or large number of malicious samples. In particular, I found it the most useful when it finds an autoit-compiled executable. In those cases, you get the entire autoit script from taking this simple step, which is much easier to quickly analyze.