Monday, July 16, 2007

[Software :: OS :: Command Prompt] CLS is a Hack

Open a command prompt and type the following command: cls>clstest.txt. Now examine the contents of clstest.txt. You will see that it contains one character: 0x12—FF which stands for form-feed. That’s right, CLS clears the screen by merely scrolling the previous contents out of sight by printing out a form-feed character; well, almost merely.

If you are using XP, set the command prompt window to have a larger buffer and try this command: more /p clstest.txt. It displays the contents of the file, expanding any form-feed characters it finds. What happens is that the display scrolls the previous contents up, effectively clearing the screen, but does not clear the buffer; you can still scroll up to see the previous contents. Using the CLS command however does erase the contents of the buffer.

CLS prints a form-feed character because when it was first created back in the days of (MS-)DOS there were no back-buffers and screens were a fixed size.

It is interesting to see some of the indelible backwards compatibilities.

[Software :: OS :: Command Prompt] NULL Character (and other Control Codes) at Command Line

You can type control codes at command prompt in Windows (and DOS) by pressing the corresponding key with the Control key. Get it, Control key for control code?

The connection between letter and code is simple: add 0x40. That is, for control code 1, add 0x40 to get 0x41 which is the ASCII code for ‘A’, therefore press Ctrl+A to get character 1 (SOH).

But, the alphabet only accounts for 26 of the first 32 characters. What about codes 27-31? The correspondence remains the same. Character 27 (ESC) is 0x1B+0x40=0x5B which is ‘[’, 28 (FS) is ‘\’, 29 (GS) is ]’, 30 (RS) is ‘^’, and 31 (US) is ‘_’.

Unfortunately, since ‘_’ is a shifted character, it requires holding Shift to create, so it is not possible to press Ctrl+Shift+- to get character 31 that way (and for the curious, no, Ctrl+- won’t work). For that, you’ll have to resort to the classic Alt+Numpad method (Alt+31 on the numeric pad).

Conversely, you cannot press Alt+0 to type character 0 (NUL). To get null, you have to use the Control key. Remember that it requires adding 0x40, so zero plus 40 is, well, 40. That’s right, 0x40 (64) is ‘@’ so, pressing Ctrl+Shift+2 (or just Ctrl+2) gets some sort of reaction. However, it does not seem to produce the expected effect, probably because nulls are string terminators for any software that uses ASCIIZ encoding (a very common method). (So Ctrl+2 is Null; that explains why it can sometimes be used as an abort chord similar to Ctrl+C or Break).

In practice (in at least XP’s command line), Ctrl+@ causes the prompt “More? ”, after which it passes whatever the user enters to the program as a parameter. For example the command echo ^@ followed by the the user entering testing would print out testing because the string was piped into the echo command. Another example: dir ^@ allows the user to select the file/directory to list (entering /s at the prompt would display all subdirectories). There does not seem to be a way to prevent the prompt from being displayed (not even by redirecting to nul).

No doubt, some creative and enterprising individual will be able to exploit this feature to enhance batch files.

Wednesday, July 04, 2007

[Computers :: Security] Virus Clues

If you are downloading files from a P2P network, then be especially wary of viruses.

One dead giveaway is when a search gives you moderate results, but then you get a few results (usually at the end of the search) that suddenly have hundreds, or even thousands of sources, particularly if those files are of wildly different sizes. What happened, did you get really lucky and manage to find a hidden cache of the file you were looking for? No, those few results that show hundreds or thousands of sources for the file you were searching for are not real, they are viruses that a bad server returns. When you do a search, the servers that are queried return a list of sources for that file that they know of. There are fake servers and virus pits that always respond with a very large number of sources no matter what the file is. They return a large number as bait, and if someone attempts to download the file, they receive one of a number of fakes (possibly even dynamically created), which are infected with viruses and other malware, regardless of what file they were trying to get.

Yet another dead giveaway is when you get a ZIP file that contains three files, an EXE, a DLL, and a TXT, especially if the files have gibberish filenames. This is a common dummy file that virus pits send out which contains an encrypted virus (checking the binary contents looks like it’s not an executable, but it is merely XOR-encrypted and is indeed a virus). What’s interesting about this one is that it usually uses the tag ZWT. ZWT is an actual scene group that does release “legitimate” cracks and such. It is unknown whether the owners of the virus pits that send out fake ZWT-tagged files targeted ZWT on purpose or not, but since it is the only group who’s name is used in the fakes, it may very well be the case.

One more virus-infected fake pattern that is making the rounds on the donkey network is the one where the resulting files contain an NFO file and an EXE. The EXE is the virus, and the NFO contains nothing but a numerical url: eg www.209193.com, www.39520.com, etc. These ones often contain the name of a piece of software or something in the names, and even version numbers to look even more legitimate. However, they don’t usually contain release group names.

As usual, be very wary of anything you download, especially from P2P networks, and in particular when looking for warez. Always check files that you download with at the very least a virus scanner, if not a trojan scanner, worm scanner, rootkit scanner… You can also run them through online scanners such as Jotti’s, Virus.org, and Virustotal.

If everyone kept themselves clean, the whole world would be cleaner overall. If you must pirate, practice safe piracy.

[Computers :: OS] Unexpected DIR Results for Numbered Files

If you have ever used the DIR command to list numbered files in a command prompt and been confused by the output, it may have been due to SFNs.

Here is an example to demonstrate the problem. In a directory with files with long names and numbered filenames, you might type dir *1.txt to list all files that end in a 1. However you may end up getting a bunch of files that do not end in a 1 mixed in with the results.

What happened? Remember that each file that has a long filename has a DOS compatible (8.3) SFN associated with it. These are usually six characters from the filename followed by a swung-dash and a numerical counter. In other words, “Long Filename.txt” would not only have that as it’s name, but also “LONGFI~1.TXT”. And there’s the 1!

If there are multiple LFN files (that are too long or have spaces) that begin with LONGFI—eg “Long File.txt”, “Long Fi.txt”, etc.—then they will be saved as LONGFI~2.txt, LONGFI~3.txt, and so on. Therefore you may get weird results for dir *2.txt, dir *8.txt, dir *516.txt

There does not seem to be a way around this, but using the /X switch can at least reveal the source of the unexpected results.

This page is powered by Blogger. Isn't yours?