Related
I need to check which key the user must hit to boot their PC from a USB key or a CD.
Does it depend on the BIOS maker, or on the maker/model of the motherboard?
I was told about the nice, open-source Speccy to get some information on the hardware, but is there a library that I could use to get the same info from a (.Net) program and tell users precisely which key to hit on their very own computer?
Thank you.
There is no way you'll be able to find this out without building a comprehensive library of every single type of motherboard and manufacturer ever made, including any BIOS updates that might change it.
You should just ask the user to follow on-screen instructions when their computer to boots to select the boot device, and maybe offer some likely suggestions ("It will ask you to press a function key...")
At the stage you want to press enter or key, .NET will never be available.
In general, the Screensaver will run when we do nothing for a period of time.
Now i wanna know how to get the unactive time.
In another word,i want to make a program which would run a function if we do nothing for a period of time.
Now i can use mouse or keyboard hook to solve the problem.
But you know,it needs administrator permissions. In another word,if in win vista or win 7,it is nauseating because of the UAC.
I need an API such to get last windows active time.
The CallNtPowerInformation() API is to get the last power information
I should use GetLastInputInfo()
Look into CallNtPowerInformation() and request a SYSTEM_POWER_INFORMATION structure.
Is it possible to programmatically disable UAC in Vista? Or, can I make my application run unrestricted by the UAC setting in any way? FYI, the application needs to mount hard drives on the fly, which is why I can't ask for UAC permission each time...
Update:
I'm looking for something in line with what Kosi2801 mentioned, basically to ask the user to always start the program in an 'elevated' mode. I'd want the permission to be a 1 time thing, I'm not saying that I programmatically disable UAC without asking permission first. I'm sure there are lots of programs that need to operate in this mode (especially hardware-related programs) so there should be some type of way to accommodate it.
Set the EnableLUA DWORD value in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System to 0 and reboot.
this will disable UAC without a problem, i would do it to all your users, with or without permission is up to you, because the vista UAC is so horrid that i do believe the less people that have it on the better (in vista only) it is now better in win7.
have fun with my registry trick :)
works in win7 as well, let me know how you got along with it.
You can't programmatically disable UAC, but you can force the program to run with elevated privileges from the start, so it doesn't prompt each time.
That will cause it to prompt once on startup, but not each time it needs access.
To do this, you'll need to create a manifest file and set <requestedExecutionLevel level="requireAdministrator">
See MSDN for details.
The purpose of UAC is to prevent executing unwanted applications. If it was possible to disable it programatically it would be worthless.
I posted a somewhat granular (but ugly) solution here
http://stackoverflow.com/questions/5344021/bypass-uac-in-vbscript/34445992#34445992
It only works if you can kick off the application from the task scheduler. I have it running on two Windows 7 laptops. It is an administrative solution. You need administrator privilege to implement it. I use it for powershell and for my UPS power backup application. I suspect I'll find other uses.
I created a small application to do this, but basically there are 4 registry keys you need to set.
C# example:
Microsoft.Win32.Registry.SetValue("HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System","EnableLUA", 0);
Microsoft.Win32.Registry.SetValue("HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System", "ConsentPromptBehaviorAdmin", 0);
Microsoft.Win32.Registry.SetValue("HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System", "PromptOnSecureDesktop", 0);
Microsoft.Win32.Registry.SetValue("HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Action Center\\Checks\\{C8E6F269-B90A-4053-A3BE-499AFCEC98C4}.check.0", "CheckSetting", StringToByteArray("23004100430042006C006F00620000000000000000000000010000000000000000000000"), RegistryValueKind.Binary);
My application runs as a service every 5 minutes to "fight" Group Policy on this, which is an absolute annoyance for a developer machine.
https://github.com/zleight1/DisableUAC
Disabling UAC programmatically would defeat its purpose as this would then also be possible to be done by malware, worms, trojans and virusses and have no real security-effect at all.
You could require to run your application under the admin-account or (I think) let Microsoft somehow sign your application.
There may be other ways I'm not aware of, but none of them is programmatically!
UAC is a necessary evil alike the use of semaphores on a city. I suggest adapting to the new paradigm. I personally don't like UAC; but I understand the purpose and benefits. Unfortunately, we all created this monster. Lest's go back to 1983, do a short assessment of the changes throughout the years and then, we will understand. Of course, if the intent is for private use, anything is possible, as pointed above; but it would be risky and become a black hole liability.
That would defeat the object of UAC. So no, you can't.
I want to write a small utility in MFC which sends the Ctrl+Alt+Del message to OS. Can any one help me how do I achieve this? I tried:
::PostMessage(HWND_BROADCAST, WM_HOTKEY, 0, MAKELONG( MOD_CONTROL | MOD_ALT, VK_DELETE));
But this is not working.
I want to send Ctrl+Alt+Del not to invoke TaskMgr.exe. Also, it is for my local OS (Windows XP Service pack 2). Basically I want to use this application to lock my machine and schedule some actions along with locking.
This is not a keystroke you can simulate. It's called the "Secure Attention Sequence".
Here's how to invoke it FROM A REMOTE DESKTOP (XP+ solution):
include <shldisp.h>
IShellDispatch4 *pShell;
CoInitialize(NULL);
HRESULT hr = CoCreateInstance(CLSID_Shell, NULL, CLSCTX_INPROC_SERVER,
IID_IShellDispatch, (void**)&pShell);
if(SUCCEEDED(hr))
pShell->WindowsSecurity();
CoUninitialize();
The only solution to invoke it from the local desktop is to use SASLib. It's not public. Write a note to saslib#microsoft.com to request it.
EDIT: Wait! You want to lock the machine? Just call LockWorkStation()! Click the link for more info about header file, lib file et all other details.
Since VNC can let you do this to a remote system, it must be possible. If I were you, I'd trawl through the source to UltraVNC. Then I'd post the answer the here :)
Do you need to send control+alt+delete or do you just want to bring up the task manager?
If you just need to bring up the task manager you can simply run \Windows\System32\taskmgr.exe
I know it's an old questions but I am posting my solutions here in case someone looking for a solution arrives here. The part1 and part2 articles explain how Winlogon registers the CAD sequence and provides code examples on how to use it.
Send CAD and Unlock workstation for Windows XP - Part 1 (free)
Send CAD and Unlock workstation for Windows XP - Part 2 (free)
SasLibEx for Vista and higher (sorry, this is not free)
Wouldn't it be easier to just ask the machine to shut down or logout? That key combination isn't really a good idea? You can send these messages.
Can't you start a screensaver and it will take care of the locking for you? I don't have a Windows machine available right now, but I recall one could lock the workstation like this.
Call the SendSAS function to achieve this.
Just curious here: is it possible to invoke a Windows Blue Screen of Death using .net managed code under Windows XP/Vista? And if it is possible, what could the example code be?
Just for the record, this is not for any malicious purpose, I am just wondering what kind of code it would take to actually kill the operating system as specified.
The keyboard thing is probably a good option, but if you need to do it by code, continue reading...
You don't really need anything to barf, per se, all you need to do is find the KeBugCheck(Ex) function and invoke that.
http://msdn.microsoft.com/en-us/library/ms801640.aspx
http://msdn.microsoft.com/en-us/library/ms801645.aspx
For manually initiated crashes, you want to used 0xE2 (MANUALLY_INITIATED_CRASH) or 0xDEADDEAD (MANUALLY_INITIATED_CRASH1) as the bug check code. They are reserved explicitly for that use.
However, finding the function may prove to be a bit tricky. The Windows DDK may help (check Ntddk.h) - I don't have it available at the moment, and I can't seem to find decisive info right now - I think it's in ntoskrnl.exe or ntkrnlpa.exe, but I'm not sure, and don't currently have the tools to verify it.
You might find it easier to just write a simple C++ app or something that calls the function, and then just running that.
Mind you, I'm assuming that Windows doesn't block you from accessing the function from user-space (.NET might have some special provisions). I have not tested it myself.
I do not know if it really works and I am sure you need Admin rights, but you could set the CrashOnCtrlScroll Registry Key and then use a SendKeys to send CTRL+Scroll Lock+Scroll Lock.
But I believe that this HAS to come from the Keyboard Driver, so I guess a simple SendKeys is not good enough and you would either need to somehow hook into the Keyboard Driver (sounds really messy) or check of that CrashDump has an API that can be called with P/Invoke.
http://support.microsoft.com/kb/244139
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters
Name: CrashOnCtrlScroll
Data Type: REG_DWORD
Value: 1
Restart
I would have to say no. You'd have to p/invoke and interact with a driver or other code that lives in kernel space. .NET code lives far removed from this area, although there has been some talk about managed drivers in future versions of Windows. Just wait a few more years and you can crash away just like our unmanaged friends.
As far as I know a real BSOD requires failure in kernel mode code. Vista still has BSOD's but they're less frequent because the new driver model has less drivers in kernel mode. Any user-mode failures will just result in your application being killed.
You can't run managed code in kernel mode. So if you want to BSOD you need to use PInvoke. But even this is quite difficult. You need to do some really fancy PInvokes to get something in kernel mode to barf.
But among the thousands of SO users there is probably someone who has done this :-)
You could use OSR Online's tool that triggers a kernel crash. I've never tried it myself but I imagine you could just run it via the standard .net Process class:
http://www.osronline.com/article.cfm?article=153
I once managed to generate a BSOD on Windows XP using System.Net.Sockets in .NET 1.1 irresponsibly. I could repeat it fairly regularly, but unfortunately that was a couple of years ago and I don't remember exactly how I triggered it, or have the source code around anymore.
Try live videoinput using directshow in directx8 or directx9, most of the calls go to kernel mode video drivers. I succeded in lots of blue screens when running a callback procedure from live videocaptureing source, particulary if your callback takes a long time, can halt the entire Kernel driver.
It's possible for managed code to cause a bugcheck when it has access to faulty kernel drivers. However, it would be the kernel driver that directly causes the BSOD (for example, uffe's DirectShow BSODs, Terence Lewis's socket BSODs, or BSODs seen when using BitTorrent with certain network adapters).
Direct user-mode access to privileged low-level resources may cause a bugcheck (for example, scribbling on Device\PhysicalMemory, if it doesn't corrupt your hard disk first; Vista doesn't allow user-mode access to physical memory).
If you just want a dump file, Mendelt's suggestion of using WinDbg is a much better idea than exploiting a bug in a kernel driver. Unfortunately, the .dump command is not supported for local kernel debugging, so you would need a second PC connected over serial or 1394, or a VM connected over a virtual serial port. LiveKd may be a single-PC option, if you don't need the state of the memory dump to be completely self-consistent.
This one doesn't need any kernel-mode drivers, just a SeDebugPrivilege. You can set your process critical by NtSetInformationProcess, or RtlSetProcessIsCritical and just kill your process. You will see same bugcheck code as you kill csrss.exe, because you set same "critical" flag on your process.
Unfortunately, I know how to do this as a .NET service on our server was causing a blue screen. (Note: Windows Server 2008 R2, not XP/Vista).
I could hardly believe a .NET program was the culprit, but it was. Furthermore, I've just replicated the BSOD in a virtual machine.
The offending code, causes a 0x00000f4:
string name = string.Empty; // This is the cause of the problem, should check for IsNullOrWhiteSpace
foreach (Process process in Process.GetProcesses().Where(p => p.ProcessName.StartsWith(name, StringComparison.OrdinalIgnoreCase)))
{
Check.Logging.Write("FindAndKillProcess THIS SHOULD BLUE SCREEN " + process.ProcessName);
process.Kill();
r = true;
}
If anyone's wondering why I'd want to replicate the blue screen, it's nothing malicious. I've modified our logging class to take an argument telling it to write direct to disk as the actions prior to the BSOD weren't appearing in the log despite .Flush() being called. I replicated the server crash to test the logging change. The VM duly crashed but the logging worked.
EDIT: Killing csrss.exe appears to be what causes the blue screen. As per comments, this is likely happening in kernel code.
I found that if you run taskkill /F /IM svchost.exe as an Administrator, it tries to kill just about every service host at once.