The BO-server and other
File Name "Games"
In its "generic form," the BO server has a Long File
Name of: .exe — that's a space plus a period and
then "exe" — but your mind has been tricked if
you think the name of the file is a space with the usual EXE
extension. The truth is that neither its LFN nor
its DOS filename have any extension at all! It only appears
that way in the LFN. The DOS filename is: "EXE~1" (without the
quotes) — and that's all there is to it. No extension!
Well,
that's not exactly true, the DOS 8.3 extension for a file
that doesn't appear to have one is actually three blank spaces. DOS
uses spaces to "pad" filenames that have less than eight
characters in the name or extension portions of a file's
name.
Here's an example:
________8-bytes________.___3____
45 58 41 4D 50 20 20 20-20 20 20 20 00 7A 8D 56
E X A M P -- -- -- (spaces)
32 26 32 26 11 00 82 56-32 26 03 1B 54 00 00 00
This is the DIRECTORY record (in hex bytes) of a simple DOS ("8.3")
filename under the Microsoft® Windows 95™ VFAT file system.
The name portion is "EXAMP" padded with three
spaces. But there's no extension name, so DOS pads
those 3 bytes with spaces as well.
The 12th byte, a 20(hex) in this
example, is always the attribute byte which signifies a file's
status as archive, read-only, hidden or system, or if it is
actually a volume or directory name and not a file at all. The other bytes
indicate dates and times of file creation or modification, beginning cluster
location, and file size.
So, why did the authors of Back Orifice choose " .exe" for the
default name of their trojan? I'm sure they would admit that it might be a
bit humorous watching users trying to find it in Windows95/98™. Let's
quickly review why this could frustrate the average user: The Windows
Find/Files program assumes that a single period typed into its "
Named" box followed by three more characters which it can identify as a
filetype in the registry must be an extension name. It does just fine
with filenames like "us.economy.il.gif" or "pgp.exe.sig."
But, if you try to find the file "us.search.gif.gif" by just
looking for this LFN's name portion, you'll never find it. Why?
Because it will assume you are searching for a .gif filetype called
"us.search."
And just like DOS, Windows95/98™ also assumes that any number of
leading spaces before a filename are just that. You can add one
or more spaces in the middle of a filename, but you can't add
any in front! If you try to rename a file called "pgp-now.gif" with
leading spaces, you'll get this error:
So, logically, using [space . exe] shouldn't be any different
than looking for just the EXE extension. In a DOS window, you can put
any number of spaces between the DIR command and .exe (or none at
all), and you'll get a listing of all the executables there. But
try this with the Find/Files program and it seems to act
really weird: it comes up with nothing
— not even the BO-server program can be found
when you enter space .exe or even ".exe" all by itself!
(More about this later.) Yet, a search using the wildcard
"*.exe" will list the BO trojan along with every
executable in the SYSTEM directory! See the humor?
The DOS filename (EXE~1), however, is close to being unique*.
Thus the reason we can find it so quickly when using the DIR command
in a DOS window. It's too bad that most users today have given up on trying
to learn any of the DOS commands. DOS is still very useful at times!
[ *The BO server filename comprised of both its DOS (8.3)
name and " .exe" Long File Name
is unique.]
In an attempt to create a file with the same name as the default BO
trojan, I tried to rename files to ".exe"
(without a leading space) and create new ones in a DOS window. Here's an
example using the DOS command "copy con" to make a new file:
Getting back to the apparently weird behavior of the Find/Files program: If
you copied my procedure above and made an EXE~1 file (without a space in the
name, of course), you'll see that searching for ".exe" using
Find/Files comes up with this file name! So, it's not quite as illogical as
it seemed to be before.
I continued to try the standard Windows95/98™ applications :
But neither DOS nor Windows will ever allow a user to create a file called:
"(space).exe" as the authors of Back Orifice surely knew.
The reason for the name seems to have been a cool alignment of its
stealthy nature (close to invisible under the standard Windows
95™ installs) and what I believe to be more important: the fact
that a file named " .exe" would never come into conflict
with a user's files! ( Thus, the user would never be alerted to an
attack by having one of his files cease to function when BO installs itself:
there's no chance of an accidental overwrite by either the BO server
or the user.)
The only way a file with this name can be created is by a program which
avoids both the Windows and DOS functions normally used to name a file.
Here's a comparison of the BO server name and a few others in a hexadecimal
representation of the machine code. The Long File Name comes before the DOS
name on a disk. Let's look at the BO server filename
first:
41 20 00 2E 00 65 00 78-00 65 00 0F 00 BF 00 00
(space) . e x e
FF FF FF FF FF FF FF FF-FF FF 00 00 FF FF FF FF
45 58 45 7E 31 20 20 20-20 20 20 20 00 1D B4 63
E X E ~ 1 -- -- --(3 spaces)
2E 26 2E 26 00 00 65 59-18 21 5A 11 00 E8 01 00
A LFN begins with a 01 or 41 (hex). ( If it starts with a 01h, there will be
more records in the chain holding the name. A 41h means that only one record
is needed to hold the name.) Within the LFNs, two hex bytes are used
for each character (it's called the unicode system). Thus, the
"20 00" which follows the 41h (see above), represents a leading
blank space at the beginning of this file's name.
Looking at the row of hex bytes starting with "45 58 45," you'll
notice a string of spaces (or 20's in the hexadecimal code). The
three which I've underlined together are in the position where a DOS
filename's extension would appear. Well, there's no extension name
here; just 3 spaces, as I said at the beginning of this essay.
(Compare this to the "wget.exe" file shown next.)
I picked this file because it was short, had a Long File Name
and an EXE extension:
41 77 00 67 00 65 00 74-00 2E 00 0F 00 A9 65 00
w g e t . e
78 00 65 00 00 00 FF FF-FF FF 00 00 FF FF FF FF
x e
57 47 45 54 20 20 20 20-45 58 45 20 00 72 D1 66
W G E T -- -- -- -- E X E
85 25 29 26 0F 00 66 B8-71 25 29 03 00 7C 02 00
The last two examples are the before and after representations of
what the file SYSMON.EXE turned into after I changed its name to ".exe"
in a DOS window. Note that this file ( like all of the Win95 system files) does not have a
LFN associated with it:
53 59 53 4D 4F 4E 20 20-45 58 45 20 00 00 65 59
S Y S M O N -- -- E X E
18 21 2E 26 02 00 65 59-18 21 C1 23 00 FE 00 00
And after making the change to ".exe":
41 2E 00 65 00 78 00 65-00 00 00 0F 00 BF FF FF
. e x e
FF FF FF FF FF FF FF FF-FF FF 00 00 FF FF FF FF
45 58 45 7E 31 20 20 20-20 20 20 20 00 65 59
E X E ~ 1 -- -- -- (spaces)
18 21 2E 26 02 00 65 59-18 21 C1 23 00 FE 00 00
Regarding the SYSMON file: If you tried out the same name change, or used
some other EXE file, don't forget to change it back again at the DOS prompt
with RENAME. Like this:
C:\WINDOWS > ren EXE~1 SYSMON.EXE [enter] (If you used
a file that didn't have a LFN to begin with, then use ALL CAPITALS so it's
changed back to a conventional 8.3 DOS name.)
I also thought it rather interesting when I tried to execute the SYSMON
program from the DOS prompt (while it was still named EXE~1 ) that
DOS replied back with: "Bad command or file name"! Yet, I had no
problem starting the program in an Explorer window. (The program itself
hadn't changed, only its name.)
Oh well, just another one of those
strange side-effects when using a filename that shouldn't really exist in
MS-DOS™ or Windows™!
The
BO Trojan page.