Saved Bookmarks
| 1. |
Solve : File name problem...? |
|
Answer» I have a batch file "Test.bat": I am sure a script can detect itself, Simply opening a file doesn't constitute "in-use". The call to CreateFile() would need to explicitly lock the file, by not specifying any of the FILE_SHARE_X flags. For example, if the CreateFile() is passed FILE_SHARE_READ, other programs can open the file for reading, but cannot write to the file or open it with write flags, or delete the file. FILE_SHARE_WRITE will allow programs to write to the file but not read or delete it, and FILE_SHARE_DELETE will allow the file to be deleted. Larry Osterman writes about this, and although he doesn't explicitly note anything to do with batch files there is an implication there; he notes that by default, DOS applications would open files in a manner so that any other program could access them, because of the single-tasking nature of DOS nobody considered this to be a problem. Therefore it's safe to assume that CMD.EXE opens batch files in the same mode that command.com does- that is, in a mode whereby the file is free to be changed (FILE_SHARE_WRITE+FILE_SHARE_READ+FILE_SHARE_DELETE). He also mentions that the NT Loader will open Executables with the FILE_SHARE_DELETE flag; this means that the file cannot be opened for READ or WRITE access by any program. additional invocations of the executable don't cause a problem, because the loader simply uses the same Mapped View of the executable file that it created the first time around. It's not as cut-and-dried as "if the file is open, no other program can access it". Wether that is truly the case for cmd, I don't know. It's entirely possible it opens the batch file, reads the next line, and then closes it, too.Sorry, you are right and I was wrong. I was remembering past experiences before CMD.EXE and before Windows 98, possibly back in the days of DOS v3.?, and I learnt then to expect grief from a *.BAT script if it tried to alter itself. I assumed the same was true now. My more recent experience with XP is that the O.S. may complain that a file is in use when I try to delete it, so I thought my old memories still applied. Sorry Regards Alan Quote from: ALAN_BR on September 25, 2010, 02:03:18 AM I was remembering past experiences before CMD.EXE and before Windows 98, Alan, this is just my 2 (euro) cents WORTH, but I don't really think you have any reason to apologise or say 'sorry' to anybody over this. You may have been inaccurate to say that a batch script is prevented from modifying or deleting itself, but you are certainly correct in your recollection that writing self-modifying code can be a risky business. A script that cuts the legs from under itself can lurch to DESTRUCTION. Having said that, self-modification is not always a bad thing. There is a good summary here http://en.wikipedia.org/wiki/Self-modifying_code As Wikipedia notes, "Because of the security implications of self-modifying code, all of the major operating systems are careful to remove such vulnerabilities as they become known. The concern is typically not that programs will intentionally modify themselves, but that they could be maliciously changed by an exploit." and "Self-modifying code is also sometimes used by programs that do not want to reveal their presence — such as computer viruses and some shellcodes. Viruses and shellcodes that use self-modifying code mostly do this in combination with polymorphic code. Modifying a piece of running code is also used in certain attacks, such as buffer overflows." In this regard, I am curious about the intentions of the OP. Thank you Salmon I remember the good old days when an anti-virus was pleased with itself if it could find and delete a suspect batch file. The I.T. department chose one that excelled in deleting any batch file that had the command FORMAT C:\ I had problems with self modifying code. I created a batch file called CD#.bat which LOOKED for arguments, and in the absence of arguments would skip to the end and execute the final line, which was something like CD C:\z\z\z\z\z\z\z\z\z\z\z\z\z\z\z\z\z\z\ If it was given the argument '#' it would alter the final line to aim at whatever the current path was, and the next day I immediately returned to yesterday's weird and wonderful directory with CD# Typically the new path was one extra 'z\' I tried to design self modifying code but failed. I finished with a "template" which CD#.bat duplicated as CD#.TMP The template was identical to CD#.BAT excepting the final line was "CD " without any CRLF or CtrlZ, then CD#.bat invoked CD >> CD#.TMP Then CD#.BAT deleted itself and renamed CD#.TMP as CD#.BAT That at least was the result I wanted, but achieving the result involved the use of intermediate scripts. The purpose of C:\z\z\z\z\z\z\z etc was that the first z\ held the first stage of a software product, and successive z\ held the previous plus a new feature, and the final z\ held the final product with all features. If a feature was found to be broken it was easy to test its operation at each z\ to identify what broke it and then fix it. This was when CVS etc version control was not available, and every man had to "roll his own". I remember the aggravation when the I.T. dept changed to an anti-virus which deleted my master template. It assumed that any *.BAT was up to no good and had to be deleted if it had a final command without a terminating CRLF I remember the wonderful feeling of revenge when the IT department went round one night with a FAST application to detect any unlicensed software, and the FAST application choked when it ENCOUNTERED my path with 80 or more 'z\' in a line. (I forget what the character length was for a command.com command, but I took my path up to the limit) This is a memory worth keeping ! ! Regards Alan |
|