Application Security Testing: An Integral Part of DevOps
ObjectiveFor long I've benefited from the numerous articles and codes at CodeGuru so I thought, that this is the right time I contribute something to CodeGuru.
This is a small application ... nothing special about it. But it took me quite sometime to find out how to do it. My objective was to write an application that launches itself at Windows startup. That's simple ... most of you would say. And you're right. You can do this in many ways, for example.. you can modify the Autoexec.bat or you can change the Win.ini file. You can also put the application into the Windows Startup group. There is something common in all of these approaches --they can easily be prevented from launching at Windows startup. Anyone can use the msconfig utility to do so, or they can just edit the Autoexec.bat or Win.ini files to prevent the application from launching at Windows Startup.
I wanted to build an application, which cannot be easily prevented from launching
at Windows Startup. I knew the trick lay in the registry.. So I started my R&D on the
Windows Registry. I found that under the Registry Key:
MyComputer\HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersionHerein lies seven subkeys:
These keys are what hold the secret to solving the problem we're addressing here. Under each of these Subkeys a Name - Data Pair has to be inserted where Name is the application name and Data is the fully qualified path of the executable.
There are subtle differences between each of these Subkeys. For example, if you make the entry under the subkey Run or RunServices, the application will be launched at Windows Startup but the application entry would be visible from the msconfig utility. So anyone can prevent your application from launching by making changes with the msconfig utility. Hence this is not a solution. However if you make the entry under RunOnce, RunOnceEx and RunServicesOnce Subkeys, the application won't be visible through the msconfig utility and hence there is a negligible chance of preventing the application from launching at Windows Startup. But there is a hitch; once the application is launched the OS removes the respective entry from the subkey. So the application won't launch again.So the trick is to continuously update the respective subkey of the registry. And that is exactly what this sample application does. For simplicity, I've made it a dialog based application, but the logic can be safely applied to any type of applications.
I still don't know whether this is the best method to do this job, but it works. I also don't know whether there is any straightforward API call to do this job. If you find any way do let me know at firstname.lastname@example.org. I'd be grateful.
InstructionsOnce youve downloaded the demo project (below), follow these instructions to install and configure this applications.
This project has been developed in Microsoft Visual C++ 6.0 Enterprise Edition on a Win98 system. So you'll need to build the project, and run it. After the application is terminated just copy the Boot.exe into your C: drive. This is because it has been hard coded to run from the C: drive. However if you so desire, you can change this by editing the CBootDlg::OnInitDialog() function.
You'll have to change the following line of code to launch the application at Windows Startup from which ever path you want:
If you download the applications, simply copy the executable to your C: drive and run it once. Reboot. Youll find the application launching again the next time your Windows starts!
DownloadsDownload demo project 15 KB
Download only the executable 192 KB