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()
Related
I have a classroom with ~20 PCs. One for the teacher and all others are for students. They all have pre-installed licensed Windows 7 Home Premium (cause reasons) and reinstall OS to another is not an option :( Also they all are in same work-group (in one net).
Is there any tools (like Active Directory \ VNC \ "Microsoft Garage Mouse without Borders" etc.) which can do exactly the same operations at exactly the same time on all students computers from the "main" teacher-pc? For example: I start this "magic" program in small window, it connects to all PCs (if it can), then I move my mouse inside it to the left and all mouses on all PCs moved the same way. Press Start - it will open Start on all student-PCs. It's some kind of botnet program (I suppose), but it will help a lot.
VNC not good, cause you must reconnect every time and do the same operations x19 times - eh...
AD as I read didn't support Home Premium (or I misunderstood?) - eh again.
If there is no such tool\tools, what kind of OS (may be some Linux distributives) can do such thing?
Well,
Let me take this in three different perspectives.
1) Sharing the screen. There comes a hardware called as screen splitter (Use the one which requires power adapter)
Pros : scalable witout using Netowrking., No lag.
Cons : View only mode, Students cannot perform any action.
2) Sharing the desktop
As you have already mentioned, there are tools like teamviewer (Internet/LAN), VNC (LAN) which can be used. They require network access hence the connection might drop at time.
Pros: Students have simultaneous access to their machine
Cons: Connection may be an issue
3)Only sharing the resources
I dont think this is of your use but Active directory in windows and LDAP or LTSP on Linux is something which helps achieve resource sharing but doesnt help in desktop sharing.
IMO: You have to either go by 1 or 2. Both at the same time cannot be achieved with a legacy.
EDIT: My asnwer is considering you as a teacher and not sys admin. In the later case, tasks might be different which can be handled in various other ways.
Years ago, there were functions in Win32 whereby the app could check to see if a user was running the app via Terminal Services/Remote Desktop. I thnk it was something like:
GetSystemMetrics(1000H)
Is there a system call one can make to check to see if a Win32 or Win64 app is being run remotely via a program like GotoMyPC or LogMeIn?
No, there is not. Those are third party apps doing their own video/input capturing and network streaming. They are plain ordinary apps as far as Windows is concerned. Terminal Services is built into Windows, which is why there are APIs to query TS status.
The only way I can (currently) think of, other than using the aforementioned API call, is also seeing if any particular processes you can identify are running (e.g. GotoMyPC or LogMeIn... they will have some process running). Without doing too much research, they may be running without actually having someone using them. If, however, they launch something to do the streaming, you could check for that.
Just to make sure that this isn't an XY problem, what is it that you're trying to do - and perhaps there is another way?
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
Is there any library or software or any way of saving the state of a single process in Windows to a file, then restoring the running process to a running state with all the memory already loaded at a later time?
I am aware that open handles will have to be re-opened, threads may have to started, etc, but can the heap and a single thread stack at least be restored?
I saw this question, but the answers are all for linux and most of them say it can't be done.
I know I can make all of my data structures serializable and do it myself, but I'd like to know if it is possible without that.
Raymond Chen (who may even kick Jon Skeet's ass when it comes to obscure Windows knowledge) says it isn't possible.
Essentially, unless your process uses absolutely no system resources (e.g. handles of any kind), there's always going to be some OS state which you can't save and restore.
The most practical way of solving this problem is to create a VM running another instance of Windows and run your process inside that:
You can make the guest OS as lightweight as possible by using nLite.
You can then use the VMWare VIX API to suspend/resume the VM programmatically.
This of course suspends the guest OS, and your process with it, solving the OS state problem.
>> •You can make the guest OS as lightweight as possible by using nLite.
To add to the above statement - The official lightweight version of Windows XP is "XP Embedded" or "Windows Embedded Standard". It is a heavily componentized version of XP that lets you slim down the XP image as small as 40 MB.
The "light weight" version of Windows 7 is Windows Embedded Standard 2011 , which is currently in Beta and available for download (connect.microsoft.com/windowsembedded)
Of course , it is not a freeware unlike NLite.
Thanks,
Srikanth
I use Virtual PC to create fresh environments for testing my installer. But I must be doing something wrong because a VPC image with Vista or XP inside is taking around 15GB of disk space (that includes VS2005/S2008 installed in them).
To create a new copy for testing I copy and paste the folder that has the .vhd, .vmc and .vsv files inside. After using the new VPC image for testing I then delete that copied folder. This works but it takes a looong time to copy 15GB each time. Is there some faster/more efficent approach?
Use differencing/undo disks. This means when you shut down your VPC you'll be asked if you want to save changes, simply answer no and you'll be back to where you started.
Doesn't VirtualPC have a fake-write/snapshot mode? That way it should not write to your original disk at all unless you say so at the end of the session.
If it doesn't, you might seriously want to consider VMWare or VirtualBox as these do have this feature and it's REALLY useful for things like this.
Edit: it looks like VPC does have a feature like this called differencing disks. Have a look at this:
http://www.andrewconnell.com/blog/articles/UseVirtualPCsDifferencingDisksToYourAdvantage.aspx
VPC has a so called undo disk. you create sg similar like "restore point" and in vpc you can roll back to that version. ideal for testing setups.
Sound like you need to use differencing virtual hard disks rather than creating a new copy every time.
Instructions here
Another option: you can use Microsoft's ImageX to store VHDs in WIM format. If you have multiple images you are constantly reusing, this is an incredible way to manage VMs. I have a slew of Windows XP and 2003 images I keep in compressed WIM format.
You can capture the VMs by mounting them in Windows PE and then capturing them to a network drive.
Also, you mentioned cut & paste, this is not the best way to be copying large amounts of data within windows. At least use xcopy, robocopy is even faster.
Also, another option if you are looking to duplicate the images for use on other real machines, you can convert the disk to a dynamically expanding disk which will reduce the size of the vdisk making it easier to copy. This also allows for a more rapid backup, which looks to be part of what your testing does by default. The problem with dynamic disks is they tend to be slightly slower performance wise than fixed-size disks.
However, if all you are doing is using it for testing on the same machine, see the answers above. Differencing is the way to go.