Retrieving BSOD text from VM - windows

How would you retrieve the BSOD text from a virtualbox vm??
As the BSOD is text, it should be stored in the VM's memory space somewhere and probably somewhere well defined.
I have several VMs that have been configured to stop on blue screens rather than rebooting, and code is in place to take screen shots at regular intervals.
At this point my plan is to difference two images, if there are no differences ( i.e. there have been no changes on the screen) and the pixels in the 4 corners are all blue ( and the right blue) then we attempt extraction of the BSOD text, search the text for the "* STOP:" sequence to confirm it as a BSOD.
I originally planed on a quick and dirty OCR solution to extract text from the image itself, however if we can relatively easily extract it from memory we would remove the possibility of OCR errors.
I've perused the manual and API reference and haven't seen anything that seems to immediately apply.
Is it possible to access the guests memory from the Virtual Box host and retrieve the BSOD text directly from memory?
UPDATE
Just to clarify, I've considered 4 different options at this time
1) Reverse engineering the windows debug protocol and building at least a basic debugger to listen on the vm's serial port
Requires reverse engineering serial protocol, suspect this would present a fair amount of difficulty
2) Reverse engineering the Virtualbox saved state file and extracting the text from the VESA memory area that I suspect is stored in that file after saving the VM on the BSOD
I haven't been able to find documentation on this file format outside the source code itself.
3) Running OCR on the output image retrieved using the API
This may be the best way to go, requires building or setting up and training an ocr solution of some kind, outside my experience. May be relatively simple to do, constant width font/ clean image, only two colours to deal with
4) Access the guests memory directly using either an API call or by creating an extension to access/expose it in some manner
As pointed out by Warren, there doesn't seem to be an API to access the memory, may be able to write an extension to expose the vm's memory in some manner, but would require understanding of Virtualbox internals.
This is running on Solaris hosts, and some may only have one Windows vm available that may or may not boot. This VM could be any relatively recent version of windows (XP, 2003, 2003 R2, 2008,Vista, 2008 R2). I can spawn an arbitrary number of Linux based VM's, however I cannot spawn additional windows VM's due to licensing concerns. My thought to this point has been that retrieving it directly from the guests memory would be the easiest to implement, perhaps I'm mistaken in that and one of the above methods, or one I haven't thought of, would be easier to implement

If you are trying to just get the information why not just enable kernel debugging and expose it over one of the virtual serial ports? I believe you should be able to use either Debugging Tools for Windows (WinDbg) or Kernel Debugger (KD) over an I/O port. The only unique requirement because this is a VM is that the virtual serial port should be mapped to a named pipe on the host, and then the debugger on the host (or other VM since your host isn't Windows) should be configured to communicate over that pipe. Your commands would look something like this:
windbg -k com:port=\\.\pipe\<pipe_name>,pipe
kd -k com:port=\\.\pipe\<pipe_name>,pipe
There is a great blog post by the legendary Mark Russinovich that describes how he used the debugger to alter the colors of the BSOD screen. Hopefully that will provide you some additional insight into using the tools as well as narrowing down the field and getting you to the right area to extract the info you are looking for.
Here are some references to help get you started:
KB Article 151981: How to set up a remote debug session using a null modem cable
http://support.microsoft.com/kb/151981
A Bluescreen By Any Other Color
http://blogs.technet.com/b/markrussinovich/archive/2010/12/14/3374820.aspx
Debugging Tools for Windows
http://msdn.microsoft.com/en-us/windows/hardware/gg463009

It is possible to extract the guest (virtual) physical memory using VBoxManage and a debugger.
VBoxManage debugvm TestVm dumpguestcore --filename guest.dump
gdb --core guest.dump
# dump memory [phys-mem-file] 0x0 [size vm-memory]
Afterwards one can search the memory dump for string content.
See also: http://www.halfdog.net/Misc/TipsAndTricks/VirtualBox.html#ExtractGuestPhysicalMemory

Related

How to peek into source code of a built-in Powershell function?

Specifically interested in source code and workings of Set-NetConnectionProfile or Get-NetConnectionProfile, to understand how Windows resets network profiles ("Public" and "Private" in Network and Sharing Center).
I tried (Get-Command Set-NetConnectionProfile).DLL to find out which DLL supplies the code behind the command, but the string is null or empty. I was going to load the DLL in ILSpy and take it from there.
Apparently, the two commands are functions, not cmdlets. Perhaps that's why there is no associated DLL?
Is there any way to find the intermediate representation or anything of the kind related to the two commands and hopefully disassemble it into something readable?
I am ultimately interested in how Windows gets and sets the profile category for a network, as I am having troubles with Windows resetting it on its own for my internal NAT network backed by a Hyper-V virtual switch (which does not have any entry in the registry under HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/NetworkList/Profiles as is the case with say WiFi networks).
I am on Windows 10 x86_64 Education Edition, version 10.0.14393 (build 14393).

Changing Mac Hardware UUID on a Parallels 11 VM

I have a few VMs in Parallels 11, running several different versions of OS X, for automated software builds.
I recently copied those VMs to a different host, so I'd have a second set to fall back on in case of a hardware failure.
The problem: the copied VMs have the same Hardware UUIDs as the corresponding originals, and that causes a problem backing up the VMs with Time Machine, since Time Machine links backup images to machines by their Hardware UUIDs. If you have two VMs with the same Hardware UUID, Time Machine running in those two VMs will try to write to the same sparsebundle file on the backup server.
I googled the issue and found this: http://kb.parallels.com/en/11197 -- but those instructions don't work for Parallels 11: when you double-click the pvm, it is imported immediately, without asking whether it was moved or copied. When I first imported the copies, Parallels asked me whether the VMs were moved or copied, and I answered that they were copied. The KB article makes it sound like that should have made Parallels assign new Hardware UUIDs to the VMs, but that didn't happen (it did assign new MAC addresses, though).
I'm going to try finding the Hardware UUID in the PVM using a hex search; if I can find it, maybe I can change it manually, using a hex editor. It seems like a very yucky procedure, though, for something you'd think Parallels should handle itself. Is there any better way of doing this? Is this a bug in Parallels 11, or did they deliberately remove the Hardware UUID reset functionality (and if so, why)?
I was able to change it by:
Shutting down the virtual machine
Find the virtual machine bundle located on disk in Finder, right click on it and "Show package contents" on the actual .pvm file.
Then find the config.pvs file inside and open it with a text editor.
Change an arbitrary digit in the <SourceVmUuid>
value
Start the virtual machine
You can then go to:
About this Mac -> System Report -> Hardware
and inspect that the Hardware UUID has changed.

Find if imaged OS had been installed from software copied with the os image

Can we find if our software has been copied in an OS image (windows) and then deployed in another machine. The hardware details do change but it may be due to hardware upgrade or change.
Is there anything at software level which indicates that the OS image has been installed.
P.S the OS install date doesnt change after image deployment.It shows the date of original OS installation date and time and not that of the imaged one.
For example i tried to detect this using service tag,uuid and os install date changes . I thought the hardware and software details combined would result in correct detection. But the os install date dint change and hardware details changed or showed junk value during hardware upgrade . My software will be installed in the os . Then OS will be imaged. I want to detect the imaged installation
If your software is connected to the Internet this is relatively easy to solve. You arrange to 'call home': send occasional packets to a known server address containing enough information to identify the instance.
For this purpose UDP packets serve quite well. You include information about the build of your software, the operating system it is running on, some simple hardware details such as how much memory and disk, the IP address and the MAC address. From the packets logged by your server you will easily be able to tell an original instance from a clone, or an original with updated hardware in almost every instance. You may also be able to obtain highly distinctive information by a detailed inspection of hardware if you have sufficient privilege.
Please note that Windows does exactly this. If an activated copy is found running on a machine that is sufficiently different then it must be re-activated. The definition of 'sufficiently different' is not made public.
Just to be clear, what I'm describing is a heuristic, not an algorithm. I'll assume the original installation creates a GUID, and that a clone carries the same GUID. When you receive packets from installations with the same GUID containing enough information, in practice you will be able to tell the original from the clone in virtually every case. Two clones may start identical but very soon something will diverge: a network IP address, disk free space, active devices.
This may not fill all the requirements of the original question but it will work (it already does) and it's better than nothing.
Generate a GUID each time the computer boots, and include both the current GUID and the history of GUIDs previously generated each time you report to the server.
If a machine's report has a GUID missing, then you know the machine has been cloned and at least one new instance should be generated. You can determine when the cloning took place by looking for the last GUID that is remembered by both instances.
To determine which instance to consider "the same machine" as the original, if this matters, look for changes in the MAC address or computer name. If there is exactly one instance where neither of these have changed since the machine was cloned, that can be assumed to be the original. (If there are multiple instances with the same MAC address, something is badly wrong; bring it to the attention of the system administrators and let them sort it out.)
If none of the current instances has a matching MAC address and computer name, this might mean that the original machine has not been powered back up yet but will be eventually, or that it has been destroyed, or that it is permanently offline and only being used as a template. It could also mean that, by coincidence, the computer name and/or MAC address were changed after the machine was cloned but before the next report.
How best to deal with this depends on the context, but in most cases it would probably be sensible to show the original machine as a separate instance, even if you haven't had a report from it since the cloning took place, and let the system administrator manually delete it if appropriate.

Informations about processes/windows inside VMware

I was wondering if it is possible to gather information about a running virtualized system (e.g. enumerating processes, finding window captions, window positions on a windows system).
My naive approach was using ReadProcessMemory() on vmware-vmx.exe and searching for data structures like _tagWND. This didn't work out as expected. :/
I don't want to "touch" the guest system if I don't have to.
So, how could I achieve this?
There are APIs to talk to the VMware Tools inside the guest. See the VMware VIX API here.
In the list of common tasks from the documentation, there are the following guest operations that would probably do what you're after:
VixVM_ListProcessesInGuest()
VixVM_RunProgramInGuest()
VixVM_RunScriptInGuest()

Invoke Blue Screen of Death using Managed Code

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.

Resources