Disable safe mode option or F8 key
-
Dear All, I am developing an application for Windows 2000 using VC++ Version 6.0. I need to disable the F8 option so that user may not be able to boot the system in safe mode. Is there any way out to disable safe mode option, i.e disable F8 key. Thanks in advance. Regards, Rohit Dhamija
-
Dear All, I am developing an application for Windows 2000 using VC++ Version 6.0. I need to disable the F8 option so that user may not be able to boot the system in safe mode. Is there any way out to disable safe mode option, i.e disable F8 key. Thanks in advance. Regards, Rohit Dhamija
Rohit Divas wrote: Is there any way out to disable safe mode option, i.e disable F8 key. God, I hope not! If you manage to disable that I'll have to hunt you down and break both of your knees. I'll leave you with functioning fingers, though, as you'll need them to correct the error of your ways.:-D Any application that meddles with the safe operation of the OS is trash by definition, and Safe Mode is critical to the reliable operation (and recovery) of the system. I can think of no legitimate reason for breaking it, unless your application is malicious by design. "Your village called -
They're missing their idiot." -
Rohit Divas wrote: Is there any way out to disable safe mode option, i.e disable F8 key. God, I hope not! If you manage to disable that I'll have to hunt you down and break both of your knees. I'll leave you with functioning fingers, though, as you'll need them to correct the error of your ways.:-D Any application that meddles with the safe operation of the OS is trash by definition, and Safe Mode is critical to the reliable operation (and recovery) of the system. I can think of no legitimate reason for breaking it, unless your application is malicious by design. "Your village called -
They're missing their idiot."hi, Q) :-DSafe Mode is critical to the reliable operation (and recovery) of the system.... Ans) I know this very well, but our s.w required this feature (it's a security s.w) so i wanted to enquire that is there any way out to disable F8 by some means... Anyways thanks for your reply Roger, Rohit
-
hi, Q) :-DSafe Mode is critical to the reliable operation (and recovery) of the system.... Ans) I know this very well, but our s.w required this feature (it's a security s.w) so i wanted to enquire that is there any way out to disable F8 by some means... Anyways thanks for your reply Roger, Rohit
I'm still suspicious of your motives... I have to fix the damned things when they go bad. Invoking safe mode occurs very early in the boot process, right about the time that the BIOS hands off to the bootstrap loader on the MBR. That's going to be hard to catch, and may require replacing an interrupt handler at a very low level; I'm not sure how you might go about that, since you're quite limited in what you can do until the OS actually loads and takes control of the hardware. "Your village called -
They're missing their idiot." -
I'm still suspicious of your motives... I have to fix the damned things when they go bad. Invoking safe mode occurs very early in the boot process, right about the time that the BIOS hands off to the bootstrap loader on the MBR. That's going to be hard to catch, and may require replacing an interrupt handler at a very low level; I'm not sure how you might go about that, since you're quite limited in what you can do until the OS actually loads and takes control of the hardware. "Your village called -
They're missing their idiot."No dear:cool:, i am developing a anti-hacking/security s.w.... I have seen this option in an application provided by http://www.stormcoast-fortress.net/ but donot know how it works ! Rohit
-
No dear:cool:, i am developing a anti-hacking/security s.w.... I have seen this option in an application provided by http://www.stormcoast-fortress.net/ but donot know how it works ! Rohit
Interesting challenge. I know there are programs that intercept keystrokes; you can probably find a few here on CP. But loading such a routine early enough in the boot process to be effective might be tough. Perhaps a Run= entry in the registry, like so many viruses use, would be called for in this case. Have you looked at redirecting the STDIN, CIN and CON devices to your program? DOS used to allow this using the || or > characters in a batch file, but I don't know if modern Windows versions still support this. "Your village called -
They're missing their idiot." -
Interesting challenge. I know there are programs that intercept keystrokes; you can probably find a few here on CP. But loading such a routine early enough in the boot process to be effective might be tough. Perhaps a Run= entry in the registry, like so many viruses use, would be called for in this case. Have you looked at redirecting the STDIN, CIN and CON devices to your program? DOS used to allow this using the || or > characters in a batch file, but I don't know if modern Windows versions still support this. "Your village called -
They're missing their idiot."What's the point - boot-time security is a hardware problem really. Disabling safemode doesn't help if you can still stick a CD or floppy in and boot from other media. And no, nothing in usermode executes early enough to catch this. In fact nothing in kernel mode really does either, in the conventional sense. To tinker with this behavior you would have to patch NTLDR or one of the things it calls, NTDETECT.COM or the optional NTBOOTDD.SYS. *shudder* Real-mode interrupt handling - ick. You were right with your first response, when you told him it was a bad idea. -Blake
-
What's the point - boot-time security is a hardware problem really. Disabling safemode doesn't help if you can still stick a CD or floppy in and boot from other media. And no, nothing in usermode executes early enough to catch this. In fact nothing in kernel mode really does either, in the conventional sense. To tinker with this behavior you would have to patch NTLDR or one of the things it calls, NTDETECT.COM or the optional NTBOOTDD.SYS. *shudder* Real-mode interrupt handling - ick. You were right with your first response, when you told him it was a bad idea. -Blake
Blake Coverett wrote: You were right with your first response, when you told him it was a bad idea. Shhhhh. I was trying to suggest a solution that might work well enough, while still letting me with my lightning fast fingers get in there and repair the machine before the key is disabled.:suss: "Your village called -
They're missing their idiot." -
What's the point - boot-time security is a hardware problem really. Disabling safemode doesn't help if you can still stick a CD or floppy in and boot from other media. And no, nothing in usermode executes early enough to catch this. In fact nothing in kernel mode really does either, in the conventional sense. To tinker with this behavior you would have to patch NTLDR or one of the things it calls, NTDETECT.COM or the optional NTBOOTDD.SYS. *shudder* Real-mode interrupt handling - ick. You were right with your first response, when you told him it was a bad idea. -Blake
Blake Coverett wrote: stick a CD or floppy It is fairly easy to disable both of those, either through software or a "hardware lock"
"Committee--a group of men who individually can do nothing but as a group decide that nothing can be done." - Fred Allen
-
Blake Coverett wrote: stick a CD or floppy It is fairly easy to disable both of those, either through software or a "hardware lock"
"Committee--a group of men who individually can do nothing but as a group decide that nothing can be done." - Fred Allen
I didn't say it was difficult, just that it was a hardware problem not a software problem. And how exactly do you suggest disabling those via software? You can change the BIOS boot options, but they can always be changed back. You can put a password on the BIOS, but it can always be disabled by shorting the appropriate jumper. Physically control of the hardware is the only way to prevent attacks based on booting off external media. Given physical access to a computer one can always break in. (The only class of solution that prevents that seriously damages usability and uptime: encryption of the disk at the block level with decryption based on a key provided by a trusted person at boot time, combined with intrusion detection that automatically shuts down the system, loosing that key in the process.) -Blake
-
I didn't say it was difficult, just that it was a hardware problem not a software problem. And how exactly do you suggest disabling those via software? You can change the BIOS boot options, but they can always be changed back. You can put a password on the BIOS, but it can always be disabled by shorting the appropriate jumper. Physically control of the hardware is the only way to prevent attacks based on booting off external media. Given physical access to a computer one can always break in. (The only class of solution that prevents that seriously damages usability and uptime: encryption of the disk at the block level with decryption based on a key provided by a trusted person at boot time, combined with intrusion detection that automatically shuts down the system, loosing that key in the process.) -Blake
Blake Coverett wrote: disabling those via software By using the Windows service floplock.exe see Q185704 , the source code is supplied, you can disable the floppy, COM ports and I believe the CD. These can be done in the BIOS as well, of course, which can then be password protected. 100% security is not possible, but using an industrial enclosure, which has floppy, CD, and power switch behind a lockable panel, plus the case itself being locked, the box then securly fastened to an imovable object. Plus monitoring the PC on the network for a reboot.
"Committee--a group of men who individually can do nothing but as a group decide that nothing can be done." - Fred Allen
-
Blake Coverett wrote: disabling those via software By using the Windows service floplock.exe see Q185704 , the source code is supplied, you can disable the floppy, COM ports and I believe the CD. These can be done in the BIOS as well, of course, which can then be password protected. 100% security is not possible, but using an industrial enclosure, which has floppy, CD, and power switch behind a lockable panel, plus the case itself being locked, the box then securly fastened to an imovable object. Plus monitoring the PC on the network for a reboot.
"Committee--a group of men who individually can do nothing but as a group decide that nothing can be done." - Fred Allen
Ted Ferenc wrote: By using the Windows service floplock.exe see Q185704 , the source code is supplied, you can disable the floppy, COM ports and I believe the CD. These can be done in the BIOS as well, of course, which can then be password protected. Floplock does not disable the floppy or anything else at boot time, only after Windows is entirely booted and user-mode services are running. The BIOS, and passwords on it I already addressed in my last post. It is of no use unless the hardware is physically secured. Ted Ferenc wrote: 100% security is not possible, but using an industrial enclosure, which has floppy, CD, and power switch behind a lockable panel, plus the case itself being locked, the box then securly fastened to an imovable object. Plus monitoring the PC on the network for a reboot. *grins* Thank you, that was exactly what I said in the first place. It is not a hard problem to solve in hardware, but it can not be solved in software. -Blake
-
Ted Ferenc wrote: By using the Windows service floplock.exe see Q185704 , the source code is supplied, you can disable the floppy, COM ports and I believe the CD. These can be done in the BIOS as well, of course, which can then be password protected. Floplock does not disable the floppy or anything else at boot time, only after Windows is entirely booted and user-mode services are running. The BIOS, and passwords on it I already addressed in my last post. It is of no use unless the hardware is physically secured. Ted Ferenc wrote: 100% security is not possible, but using an industrial enclosure, which has floppy, CD, and power switch behind a lockable panel, plus the case itself being locked, the box then securly fastened to an imovable object. Plus monitoring the PC on the network for a reboot. *grins* Thank you, that was exactly what I said in the first place. It is not a hard problem to solve in hardware, but it can not be solved in software. -Blake
Blake Coverett wrote: solve in hardware, Perhaps we should start some flame wars about the insecurity of a stand alone Windws PCs:-D After all, if you simply steal the PC or hard drive, that is an effective way of breaking security. But disabling BIOS and floppy, CD serial port, USB ports does go a long way to making it secure. I have always said I can easily guarantee totally security on a PC!! Simply remove the power cable!
"Committee--a group of men who individually can do nothing but as a group decide that nothing can be done." - Fred Allen
-
Blake Coverett wrote: solve in hardware, Perhaps we should start some flame wars about the insecurity of a stand alone Windws PCs:-D After all, if you simply steal the PC or hard drive, that is an effective way of breaking security. But disabling BIOS and floppy, CD serial port, USB ports does go a long way to making it secure. I have always said I can easily guarantee totally security on a PC!! Simply remove the power cable!
"Committee--a group of men who individually can do nothing but as a group decide that nothing can be done." - Fred Allen
Ted Ferenc wrote: about the insecurity of a stand alone Windws PCs No, you miss the point. All of what I said about boot time security and physical access to the machine applies regardless of the operating system installed on the machine. This has been a well understood fact in security circles before there was a Windows. -Blake
-
Ted Ferenc wrote: about the insecurity of a stand alone Windws PCs No, you miss the point. All of what I said about boot time security and physical access to the machine applies regardless of the operating system installed on the machine. This has been a well understood fact in security circles before there was a Windows. -Blake
Blake Coverett wrote: boot time security I totally agree, you just need on OS that does not and can not boot from a disk. even that could be argued is not 100% secure.
"Committee--a group of men who individually can do nothing but as a group decide that nothing can be done." - Fred Allen