### Some Technical Discussions about HDKP
============================================================================
Author: Will Sort
Date: 2005-04-22
Version: 1-20050505
Keywords: HDKP, %comspec%, command interpreter, drive check, disk check, command line loop
Abstract: Relevant discussions on the algorithms and details of HDKP disk check and disk traversal
----------------------------------------------------------------------------
Background
Full name: Hard Drive Killer Pro
Version: The common version is 4.0 (including the bat version and the exe version compressed from bat), the latest version is 5.0beta
Author: Munga Bunga (Australia)
Date: The 4.0 version was finally completed in May 2001
Platform: According to the original author, this program can work in systems such as DOS/Win3.x/9x/NT/2000, applicable to 90% of computers in the world at that time, and there were no XP and 2003 at that time
Use: Destroy or "clean" all data on all hard disks, floppy disks and flash drives on the computer. Of course, because of its long history, most of the current popular anti-virus software can remove it.
----------------------------------------------------------------------------
Preamble
I first saw this batch program in the "Simple Tutorial on Batch Processing". The tutorial author listed this program as the finale in the wonderful program examples. At that time, because I had a considerable hostility to all programs with so-called Killer/Hacking and other words, I just glanced at it briefly and didn't read it carefully. Later, I saw the post posted by Brother "Shenxian Beibei" in the "United DOS Forum" reprinting this program, but for similar reasons, I still just flipped through to see if there were any noticeable replies, and then closed it casually, so that I didn't see Brother Climbing's invitation later.
In mid-April, I started to look through the old posts about batch processing in the "United DOS Forum". I saw the suggestion of "Study carefully" in Brother Climbing's top-sticked essence post index several times. Finally, I opened Brother "Shenxian Beibei"'s old post again. At this time, Brother wangsea had already completed the annotation work beautifully, and my task was just to simply enjoy the fruits of others' labor.
However, unfortunately, there are too many problems and loopholes in this program. Some problems, such as that invalid formatting switch /autoSample and :Sampledrv, obviously are not typos of the original author, but modified by someone with good intentions or a deliberate program; others, such as dedecated and elapse, I don't know if they are Australian dialects or the author's careless mistake; the remaining problems can definitely be attributed mainly to the author himself.
Of course, in order to be fair and universal for discussion, I found the original link of this program and tried to download it, but the download failed. I tried several other methods, but the versions found were no different from those of "Shenxian Beibei". Finally, I decided to still use the latter as the basis for discussion, so I am discussing only the merits and demerits of the code, not the author's merits and demerits.
----------------------------------------------------------------------------
Text
Undeniably, some advanced techniques are indeed used in the program. The most main embodiment of these techniques is the disk check program (drivechk.bat). But it should be noted that drivechk.bat is not originally created by the author himself. Its original author is Tom Lavedas , which is exactly the reason for the author's "Except for". However, maybe the author did not thoroughly understand this program and just made some simple modifications, or maybe the author quoted the early program of Lavedas, so there are some problems in this code.
The following is a section of the program that dynamically generates drivechk.bat
echo @echo off >drivechk.bat
echo @prompt %%%%comspec%%%% /f /c vol %%%%1: $b find "Vol" > nul >{t}.bat
%comspec% /e:2048 /c {t}.bat >>drivechk.bat
del {t}.bat
echo if errorlevel 1 goto enddc >>drivechk.bat
The purpose of this section is to write the following code into drivechk.bat. Brother wangsea has analyzed it, and I won't go into details.
%comspec% /f /c vol %1: | find "Vol" > nul
if errorlevel 1 goto enddc
First, the sentence "echo @echo off >drivechk.bat" is not necessary. Because drivechk.bat is a dynamically generated called program, when it is called by call, it will inherit the echo off state of the calling program.
Only when called by %comspec% /c, "echo off" may be needed, because %comspec% /c will create a new command interpretation environment, and the echo state in this new environment will be reset. Also because of this, the program can obtain the modified command line prompt through %comspec% /e:2048 /c {t}.bat, which is the statement to be written into drivechk.bat.
Second, "%%%%comspec%%%%" in the second line can be completely changed to "%comspec%". The role of "%%%%" is to delay the replacement of %comspec%, so that %comspec% is not replaced with the path of the command interpreter until drivechk.bat is executed; but this is unnecessary, because the called drivechk.bat and the calling program must run in the same environment, so there is no difference between late or early replacement.
Moreover, I suggest directly changing %comspec% to command. Because in the NT-like command line environment, %comspec% usually points to cmd.exe, which is very different from command.com. For example, the code pages in non-English systems are different, resulting in find "Vol" /c failure. And in the early MS-DOS environment, %comspec% may also point to non-standard command interpreters such as NDOS, and their switch parameters and execution outputs may all cause the %comspec% sentence to fail. The biggest problem of directly using command is that it is not in the current path or %Path% path, but that is almost impossible.
Third, "find "Vol" > nul" should be "find "Vol" $g nul", otherwise "> nul" will not be written into drivechk.bat, which may cause the message of find to "leak" when calling drivechk; and when the program is called, the author tries to avoid this hidden danger by "call drivechk.bat %%a >nul", but he may not be clear that this ">nul" is invalid for call batch processing.
Only when a batch processing is called by %comspec% /c, its output can be redirected or pipelined. But even so, there may be some outputs of executing vol %1: that cannot be shielded, such as the error message generated when accessing a non-existent or unprepared disk, because it uses error device output, not the standard console, so it is not pipelined. The solution is to add a pair of ctty nul and ctty con statements before and after %comspec% /c. However, ctty is only supported in MS-DOS and 9x command lines, and ctty is canceled in XP and other NT-like command lines. In such environments, only 2> nul can be used to redirect the error message.
Fourth, "if errorlevel 1 goto enddc" ignores many problems. In the MS-DOS or 9x command line, using vol to access an existing but unprepared disk will have Vol information output, but the program will not jump to the end at this time; in addition, it may access a read-only CD or flash drive, and there will also be Vol information output.
So, in order to remedy these two defects, the program later uses dir | find "bytes" to detect the preparation status and dir | find "0 bytes" to check the read-only CD. But the locked flash drive still cannot be correctly judged. Maybe the locking function of the flash drive was not common at that time.
The statement to detect whether the disk is readable can also be replaced with dir %1:\nul|find "\", and to check whether the disk is writable can use copy /y _writed_.tag %1: and if exist %1:_writed_.tag to judge . Of course, these statements still need to be run in the %comspec% /f/c shell. However, there are still some problems we can't think of, such as I can only create and modify files in the shared disk of the virtual PC, but can't delete it. Other such as network disks, memory virtual disks, etc., I haven't discussed them in more detail. In these details, professional programs may do better.
Fifth, there is also a relatively simple technique in the program, which is the traversal of disks in :Sampledrv. For using the For statement for loop-type traversal, it may be the convention of batch processing programming. However, this convention may not be the optimal in some cases.
In fact, in the early period, some people used a more flexible command line loop to handle many problems that For is difficult to solve. For example, when there are multiple statements after do, we must put these statements in a batch processing to be called by call. However, the characteristics of for determine that it is called multiple times during operation, and the superiority of the command line loop is that it only needs to call once, and the remaining are just shift and goto inside the program. This saves a lot of performance, because call occupies more performance resources than shift and goto.
Sixth, we discuss the necessity of dynamically generating drivechk.bat. Here, it is not the necessity of drivechk.bat, but the necessity of dynamic generation. We can guess that the main purpose of the program to go to so much trouble to dynamically generate this code instead of embedding it statically in the main program is that it can use it for the cyclic traversal of disk checks. However, maybe the author did not notice or realize that the same task can be completed with static code. This means that all the detours the program takes in writing drivechk.bat are unnecessary. We can completely find a more direct and short road.
Embed the code that the program needs to use multiple times as a module into itself, and then call this module repeatedly to achieve the effect similar to calling dynamic code. The popular understanding of the module is a whole section of code starting with a label and ending with goto end. And calling this module only needs to cooperate with call %0 : lablename and if "%1"==":" goto %2.
Structure of the calling program
...
:: Call-type call itself
call %0 : labelname
...
:: Goto-type call itself
%0 : lablename
...
:: Call-type call other Bat
call bat_name : labelname
...
:: Goto-type call other Bat
bat_name : lablename
...
Structure of the called program (may also be the calling program)
@echo off
if "%1"==":" goto %2
...
:labelname
:: Code segment of the module
...
goto end
...
:end
----------------------------------------------------------------------------
Conclusion
The purpose of me writing this article, as I mentioned in the abstract, is to try to discuss some technical characteristics and details about disk check and command line loop, not to provide technical support for HDKP or similar non-goodwill programs. Regarding the writing purpose of HDKP, I personally still hold an opposing attitude. This program is probably as the author hopes, only useful for "a very special person that does not want to be named". For me, it is just an imperfect combination of technology and conception.
I know that there are already professional third-party programs that can realize the disk check function, such as dready.com. However, as a technical category of batch processing programming, discussing it is still beneficial. It can help us understand the system working principle more deeply and be familiar with the environment we are working in. In addition, as for batch processing, it still has considerable advantages and values without relying on third-party programs.
----------------------------------------------------------------------------
References:
01. I hope some friend can write a complete annotation for this batch processing file
http://www.cn-dos.net/dosbbs/dispbbs.asp?boardid=9&id=12892
02. DOS Union Forum Q&A Essence Post Index
http://bbs.cn-dos.net/dispbbs.asp?boardid=9&id=13226
03. Hard Drive Killer Pro (HDKP) - The Hackology Network
http://www.hackology.com/programs/hdkp/ginfo.shtml
04. Safely Testing the Status of All Types of Drives - Tom Lavedas
http://www.pressroom.com/~tglbatch/testdrv.html
05. Avoiding Drive Not Ready - alt.msdos.batch
http://groups-beta.google.com/group/alt.msdos.batch/browse_thread/thread/
df0213182e13de5b/fa2abe726f972567?q=%22:_end%22+label+name&rnum=2&hl=en
=============================================================================
Last edited by willsort on 2005-8-19 at 16:25 ]
