Running a text file as an EXE file

[wylbur37]

I'm presently using Windows XP Pro.

I recently did a curious experiment where I took a 32-byte,
one-line ASCII text file containing the following characters
(without the quotes):

"..\..\diskw\usr\bin\perl w2c1.pl"

and renamed it to have an EXE extension.

Then I opened a Command Prompt window and ran it by typing its name.
Nothing seemed to happen. No messages, nothing.
Other than the fact that I heard the hard drive being accessed for
about a half second, the result was as if I had just typed nothing
and pressed carriage-return.

I then got out of the Command Prompt and went to the Windows Start-Run
textbox and typed in the above program name (including its path).
When I clicked OK, I saw a Command Prompt window come up momentarily
and then vanish a fraction of a second later.
Again, other than that, nothing seemed to happen.

I was wondering about the possible danger of something destructive
occurring from this. Is it possible that the bit patterns of the
characters in the text file might happen to be the same as the
binary instructions that would open a file and modify it, or even
delete a file? I know the odds are extremely rare, but is it possible?

Are there safeguards against this sort of thing? Are all EXE files
expected to have some sort of header such that if this header is not
present, the operating system will not try any further to run the file
even though it may have a filetype of EXE?

In the event that there aren't any safeguards, do you think the
specific example above has the ability to do any damage?
The bit pattern of the above file is as follows ...
(This has to be viewed with Courier or some other fixed-pitch font)

..\..\diskw\usr\bin\perl w2c1.pl
....+....1....+....2....+....3..
LZ: 22522566767577756665767627363276
RZ: EECEEC493B7C532C29EC052C07231E0C

 

[Doug Kanter]

I'm presently using Windows XP Pro.

I recently did a curious experiment where I took a 32-byte,
one-line ASCII text file containing the following characters
(without the quotes):

"..\..\diskw\usr\bin\perl w2c1.pl"

and renamed it to have an EXE extension.

Then I opened a Command Prompt window and ran it by typing its name.
Nothing seemed to happen. No messages, nothing.
Other than the fact that I heard the hard drive being accessed for
about a half second, the result was as if I had just typed nothing
and pressed carriage-return.

I then got out of the Command Prompt and went to the Windows Start-Run
textbox and typed in the above program name (including its path).
When I clicked OK, I saw a Command Prompt window come up momentarily
and then vanish a fraction of a second later.
Again, other than that, nothing seemed to happen.

I was wondering about the possible danger of something destructive
occurring from this. Is it possible that the bit patterns of the
characters in the text file might happen to be the same as the
binary instructions that would open a file and modify it, or even
delete a file? I know the odds are extremely rare, but is it possible?

Are there safeguards against this sort of thing? Are all EXE files
expected to have some sort of header such that if this header is not
present, the operating system will not try any further to run the file
even though it may have a filetype of EXE?

In the event that there aren't any safeguards, do you think the
specific example above has the ability to do any damage?
The bit pattern of the above file is as follows ...
(This has to be viewed with Courier or some other fixed-pitch font)

..\..\diskw\usr\bin\perl w2c1.pl
....+....1....+....2....+....3..
LZ: 22522566767577756665767627363276
RZ: EECEEC493B7C532C29EC052C07231E0C

Where would you even come up with a line like the one in the text file???
It certainly wasn't randomly chosen.

 

[David Candy]

All exe and dll (and so ocx and cpl) start with a Dos exe (run any windows program in Dos and see what happens - the message comes from the program not Dos). All Dos exe start with the initials of the Dos exe programmer, MZ.

However Com programs can be any sequence of bytes so there no way of telling except if the bytes seem legal. Last there is batch files.

Extensions don't matter at this level. CreateProcess does it best to run what it is told to.

 

[wylbur37]

Where would you even come up with a line like the one in the text file???
It certainly wasn't randomly chosen.

It was one of a bunch of script files in a server package.
I chose it just because it was a small text file.
So, yes, the *contents* certainly weren't random characters,
but that *file* was randomly chosen by me.

(But that's beside the point of my posting, of course).

 

[foxidrive]

Where would you even come up with a line like the one in the text file???
It certainly wasn't randomly chosen.

Here's an oddity that has been posted before.

Take a filename.com or filename.exe file and rename it filename.txt
Then drop to a command prompt and enter filename.txt on the command line.

For the less adventurous, the filename.com or filename.exe file will run as
normal.

 

[Doug Kanter]

Here's an oddity that has been posted before.

Take a filename.com or filename.exe file and rename it filename.txt
Then drop to a command prompt and enter filename.txt on the command line.

For the less adventurous, the filename.com or filename.exe file will run
as
normal.

Radical!

 

[David Candy]

This is different to the first case. What is happening here is that cmd looks into the file (as it ignores extensions unless it can find no other way, and if it can't find it by extension then it attempts to execute it anyway as perhaps it only checks for Win programs not OS/2 or Unix programs that CreateProcess can run - the original question) sees that it is an exe and executes it.

CreateProcess can't be tricked by spaces in the name as it tries all possibilities of what you might mean.

See Q175986 and createprocess in the MSDN. Also http://www.google.com.au/search?hl=en&q=site:blogs.msdn.com+createprocess&meta=

 

[AJR]

Lets be politically correct - "A text file (*.txt) cannot be run as an EXE
file (*.exe)". Executable files (Exe, bat, com, etc.), through programming,
originate as text files (representing valid commands/instructions) and are
converted by an Interpreter or Complier into executable file. File
extension determines what action XP will take - if there is no extension or
one XP does not recognize the "action" is usually nothing or error messages.

 

[David Candy]

You are wrong. You are confusing the rules for a particular program, explorer, with rules for the system.

 

[Sjouke Burry]

Lets be politically correct - "A text file (*.txt) cannot be run as an EXE
file (*.exe)". Executable files (Exe, bat, com, etc.), through programming,
originate as text files (representing valid commands/instructions) and are
converted by an Interpreter or Complier into executable file. File
extension determines what action XP will take - if there is no extension or
one XP does not recognize the "action" is usually nothing or error messages.

Well, if only that were true....
In a command window,ececute
copy /b notepad.exe a.wav
(or any other program exe you have).
then type a.wav.
Surprise!!!!!
windows ignores the extension does not
try to run it as a wav file but starts
a.wav as an exe,voila!! notepad starts.
So dont think that you can rely on the
extention to aviod crapware/malware.

 

[Paul Bartlett]

I'm presently using Windows XP Pro.

Then why did you crosspost to three MSDOS newsgroups? A cmd window in
Windows XP is **NOT** MSDOS. Your post is off-topic in those groups.

 

[wylbur37]

All exe and dll (and so ocx and cpl) start with a Dos exe (run any windows program
in Dos and see what happens - the message comes from the program not Dos).
All Dos exe start with the initials of the Dos exe programmer, MZ.

Is the "MZ" just an optional formality, or does it mean that any
EXE file that doesn't begin with "MZ" automatically won't be run?
or will the system then try to treat it as a COM file?

 

[David Candy]

It will be treated as a com or bat file. No MZ then it can't be an exe file. The actual tests for com/bat are not public info.

 

[wylbur37]

In my original posting, I mentioned saving the 32-character string
"..\..\diskw\usr\bin\perl w2c1.pl" (without the quotes) into an
ASCII text file, renaming it to have an EXE extension and trying to
run it, first in a Command Prompt window and then from a Windows XP
Start-Run textbox.

Although it probably (hopefully) had no ill effect, I'm still curious
as to the circumstances that occurred.

When I ran it from within a Command Prompt window, I was already
sitting on the very same subdirectory that the EXE file was on,
but yet I heard the hard drive being accessed for about a half-second.
Why did it do this?
Could it be that the system decided the file was unexecutable and
then tried to look at the other subdirectories in the PATH to find
another valid EXE file of the same name?

And when I tried to run it from the Windows XP Start-Run textbox,
it put up a Command Prompt window momentarily.
This doesn't normally happen when launching a program from the
Start-Run textbox, so why did it happen this time?
Was there some reason why the system decided to run this from
inside a DOS window?
Does running something inside a DOS window supposedly shield the
rest of the system from damage?

Finally, I'm curious whether anyone tried to repeat the experiment
that I did (namely, saving the 32-character line of text described
above into an EXE file and running it).
Not that I'm recommending it; but if anyone did it,
please let me know whether you noticed the momentary hard-drive
activity when run in a Command Prompt window, and whether you saw
the Command Prompt window appear momentarily when you ran it from
Start-Run.

 

[John]

In my original posting, I mentioned saving the 32-character string
"..\..\diskw\usr\bin\perl w2c1.pl" (without the quotes) into an
ASCII text file, renaming it to have an EXE extension and trying to
run it, first in a Command Prompt window and then from a Windows XP
Start-Run textbox.

Although it probably (hopefully) had no ill effect, I'm still curious
as to the circumstances that occurred.

When I ran it from within a Command Prompt window, I was already
sitting on the very same subdirectory that the EXE file was on,
but yet I heard the hard drive being accessed for about a half-second.
Why did it do this?
Could it be that the system decided the file was unexecutable and
then tried to look at the other subdirectories in the PATH to find
another valid EXE file of the same name?

And when I tried to run it from the Windows XP Start-Run textbox,
it put up a Command Prompt window momentarily.
This doesn't normally happen when launching a program from the
Start-Run textbox, so why did it happen this time?
Was there some reason why the system decided to run this from
inside a DOS window?
Does running something inside a DOS window supposedly shield the
rest of the system from damage?

Finally, I'm curious whether anyone tried to repeat the experiment
that I did (namely, saving the 32-character line of text described
above into an EXE file and running it).
Not that I'm recommending it; but if anyone did it,
please let me know whether you noticed the momentary hard-drive
activity when run in a Command Prompt window, and whether you saw
the Command Prompt window appear momentarily when you ran it from
Start-Run.

In XP pro running from both a DOS box and at the run prompt it caused
the printer to spit out a page of garbage. Which leads me to believe
that the behavior of a bad executable on any given system is undefined.

John

 

[David Candy]

0AF7:0100 222E2E5C AND CH,[5C2E]
0AF7:0104 2E CS:
0AF7:0105 2E CS:
0AF7:0106 5C POP SP
0AF7:0107 64 DB 64
0AF7:0108 69 DB 69
0AF7:0109 736B JNB 0176
0AF7:010B 775C JA 0169
0AF7:010D 7573 JNZ 0182
0AF7:010F 725C JB 016D
0AF7:0111 62 DB 62
0AF7:0112 69 DB 69
0AF7:0113 6E DB 6E
0AF7:0114 5C POP SP
0AF7:0115 7065 JO 017C
0AF7:0117 726C JB 0185
0AF7:0119 207732 AND [BX+32],DH
0AF7:011C 63 DB 63
0AF7:011D 312E706C XOR [6C70],BP

It appears as a valid program, at least until the first jump.

 

[John]

In my original posting, I mentioned saving the 32-character string
"..\..\diskw\usr\bin\perl w2c1.pl" (without the quotes) into an
ASCII text file, renaming it to have an EXE extension and trying to
run it, first in a Command Prompt window and then from a Windows XP
Start-Run textbox.

Although it probably (hopefully) had no ill effect, I'm still curious
as to the circumstances that occurred.

When I ran it from within a Command Prompt window, I was already
sitting on the very same subdirectory that the EXE file was on,
but yet I heard the hard drive being accessed for about a half-second.
Why did it do this?
Could it be that the system decided the file was unexecutable and
then tried to look at the other subdirectories in the PATH to find
another valid EXE file of the same name?

And when I tried to run it from the Windows XP Start-Run textbox,
it put up a Command Prompt window momentarily.
This doesn't normally happen when launching a program from the
Start-Run textbox, so why did it happen this time?
Was there some reason why the system decided to run this from
inside a DOS window?
Does running something inside a DOS window supposedly shield the
rest of the system from damage?

Finally, I'm curious whether anyone tried to repeat the experiment
that I did (namely, saving the 32-character line of text described
above into an EXE file and running it).
Not that I'm recommending it; but if anyone did it,
please let me know whether you noticed the momentary hard-drive
activity when run in a Command Prompt window, and whether you saw
the Command Prompt window appear momentarily when you ran it from
Start-Run.

In both cases it caused the printer to spit out an identical page of
garbage and then hang the DOS box. Yes it was run by command.com and not
command.exe if that helps your cause. The drive activity is just the OS
looking for the file.

So garbage in = garbage out still holds true.

John

 

[John]

0AF7:0100 222E2E5C AND CH,[5C2E]
0AF7:0104 2E CS:
0AF7:0105 2E CS:
0AF7:0106 5C POP SP
0AF7:0107 64 DB 64
0AF7:0108 69 DB 69
0AF7:0109 736B JNB 0176
0AF7:010B 775C JA 0169
0AF7:010D 7573 JNZ 0182
0AF7:010F 725C JB 016D
0AF7:0111 62 DB 62
0AF7:0112 69 DB 69
0AF7:0113 6E DB 6E
0AF7:0114 5C POP SP
0AF7:0115 7065 JO 017C
0AF7:0117 726C JB 0185
0AF7:0119 207732 AND [BX+32],DH
0AF7:011C 63 DB 63
0AF7:011D 312E706C XOR [6C70],BP

It appears as a valid program, at least until the first jump.

I see, but by accident do you think? I wonder what he is up to.

John

 

[David Candy]

Anything typed in command.com is executed by cmd.exe.

Type in Start Run

command /k ver
cmd /k ver

then type command and type ver in command. Or watch cmd start and disapper in Task Manager, specifically command executes

cmd /c <whatever you typed>

If Pro then type in command

pause [So it forces cmd to stay in memory]

Then in a different Command Prompt window

wmic process get commandline

 

[David Candy]

I dunno, but poping the SP without pushing is just going to make the stack address a random number - a crash and corruption of other programs in that Dos machine (not that this really matters in Dos running on windows).

--
--------------------------------------------------------------------------------------------------
How to lose a war in Iraq
http://webdiary.com.au/cms/?q=node/1335#comment-48641
=================================================

0AF7:0100 222E2E5C AND CH,[5C2E]
0AF7:0104 2E CS:
0AF7:0105 2E CS:
0AF7:0106 5C POP SP
0AF7:0107 64 DB 64
0AF7:0108 69 DB 69
0AF7:0109 736B JNB 0176
0AF7:010B 775C JA 0169
0AF7:010D 7573 JNZ 0182
0AF7:010F 725C JB 016D
0AF7:0111 62 DB 62
0AF7:0112 69 DB 69
0AF7:0113 6E DB 6E
0AF7:0114 5C POP SP
0AF7:0115 7065 JO 017C
0AF7:0117 726C JB 0185
0AF7:0119 207732 AND [BX+32],DH
0AF7:011C 63 DB 63
0AF7:011D 312E706C XOR [6C70],BP

It appears as a valid program, at least until the first jump.

I see, but by accident do you think? I wonder what he is up to.

John