I've seen programs like magicdisc create virtual cd drives and mount them on the machine. How do these programs trick the operating system into thinking there is a new hardware device attached to it?
I imagine I would have to write a driver for the virtual hardware, and I am comfortable in C so that doesn't sound terrible, but how do I make the OS think there is a piece of hardware attached to it that isn't?
Thanks!
Usually the operating system has different layers and libraries, at some point there is a library that sits between something above it and the actual hardware, you fake it there, if there is some sort of read sector call, you pretend to read a sector using that sector address, read it from a file, whatever. Each operating system (windows, linux, etc) may do things a different way.
Probably you are familiar with C as application level, which is above OS.
The virtual driver is a piece a software, but need to write in proper locations the settings: Registry at Windows, some config file at some Linux. You need to handle OS level calls and callbacks at Kernel level. Than you will desire the software too to communicate with your device, probably integrated into OS Shell. At least 2 layes will be , if not 3 or more.
For eg windows xp you can make a virtual graphic card(and intercept various things), for Vista not, just with a trick :)
It is very-very OS specific.
Related
I am using VmWare Workstation 14 and when I install an operating system (any of them) some programs and apps are able to identify that I am using a virtual machine.
I have seen the vm is using virtualized devices that are really named virtual. like for example VmWare Network Card or etc. Is there any way to install fake real like hardware drivers on these virtual machines? Can this simple change make the app see this vm as a real machine?
How to make this virtual machine appear as a real machine to applications?
Is there really any way?
This was asked as a yes-or-no question so my answer is:
Yes... probably. But it's a lot of work.
There's a 2006 presentation by Tom Liston and Ed Skoudis that talks about this: https://handlers.sans.org/tliston/ThwartingVMDetection_Liston_Skoudis.pdf
It focuses on VMware, but some of it would also apply to other types of Virtual Machine Environments (VMEs).
In summary, they identify as many things as they can find that would allow VM detection, which would each have to be addressed, and they also mention some VMware-specific mitigations for them.
VME artifacts in processes, file system, and/or Windows registry. These would include the VMtools service and "over 50 different references in the file system to 'VMware' and vmx" and "over 300 references in the Registry to 'VMware'", all of which would have to be deleted or changed.
VME artifacts in memory. Specific regions of memory tend to be different in guests (VMs) than hosts, namely the Interrupt Descriptor Table (IDT), Global
Descriptor Table (GDT), and Local Descriptor Table (LDT). The method by which the VM is built may allow these to appear the same in guests as they do in hosts.
VME-specific virtual hardware. This would include the drivers you mention like VmWare Network Card. The drivers would have to be removed or replaced with drivers that do not match the names or code signatures of any virtual drivers. Probably easiest to do on an open-source system, simply by modifying the driver source code and build.
VME-specific processor instructions and capabilities. Some VMEs add non-standard machine language instructions, or modify the behaviour of existing instructions. These can be changed or removed by editing the VME source code, at the cost of convenient host-guest interaction.
VME differences in behaviour. A VM might respond differently on the network, or fail at time synchonization. This could be mitigated with additional source code changes (on both host and guest) to make the network traffic look closer to normal, and providing sufficient CPU cores to the VM would help make sure it does not run more slowly than wall clock time.
Again this is from 2006, so if anyone has a more up-to-date reference, I'd love to see their answer.
I know that executable files (eg: .exe for Windows) are binaries. I know about hex files and assembly and so on. I also know about OS API's. Theoretically, I could write a web browser entirely in assembly code that uses the OS API's, assemble it with NASM and get an executable. But my question is, how do operating systems control the applications? For example, I could have a executable on Windows that writes to the video memory, and fills the screen with random stuff. I've tried this (actually) and Windows halts the application. How does it control the application? Moreover, if I have a linux executable and I attempt to run it on a Windows machine with the exact same hardware, theoretically, it should work (though it won't use any Windows API's) since the processor architecture is the same, but yet It cant. How exactly does the OS 'control' the binaries?
The operating system, in particular windows and linux protect other applications and the operating system itself from applications. So there is a protection layer that an application ideally cannot punch through running as a user.
You want to put pixels on the screen, you have to ask the operating system to do it for you. If the operating system allows a way to punch through (calling mmap perhaps having to run as root) then you can trash the computer at will, yes. The plan/design is to not let you have direct access, you are given a virtual space, a sandbox, for your application to play in, you have a virtual address space with some ram you can read and write at will, but you go outside that, you need to be shut down or at least handled in some way.
As far as what language you write applications in yes, if it is a normal windows program or linux program, then anything you can do to generate machine code for that target, asm, ada, C, etc. If you are talking specific virtual machines (java, python) then your choices get more limited. If you want to do more than play in your space, like have some sort of output other than a return value, then you have to make system calls in the way that the system requires them, which is target and operating system specific. And again, you get the right instructions or registers or memory structure or whatever is required by the operating system for that call in whatever language you are using or libraries you can link with then the rest of your program can be in whatever language, yes absolutely you want to write a web browser in assembly language using nasm, completely doable. have to create a binary format the os supports, and make the system calls as needed in the way that the system requires.
Maybe this is a cross-system issue, and maybe not. But I am just working on Mac OS X, therefore I focus on Cocoa.
As my title described, can I detect whether my application is run in an virtual environment programmatically? (not only vmware, but also some other virtual environment like Sandboxie in Windows)
There won't be any native Cocoa API's to specifically ask if you are running in a virtual machine vs real hardware.
However, if you know the potential environments you are running under you should be able to use IOKit to query the hardware of the virtual machine.
Virtual Machines will have considerably different hardware than a real Mac so you should be able to detect a real Mac vs a VM based on hardware configuration.
I can not give you any direct code, however, there is a section on Apple's site that discusses accessing hardware with IOKit in general:
https://developer.apple.com/library/mac/documentation/DeviceDrivers/Conceptual/AccessingHardware/AH_IOKitLib_API/AH_IOKitLib_API.html
IOKit is an advanced subject so if you do not have a lot of experience with the lower-level APIs you may find it a bit confusing as compared to Cocoa.
Maybe you can cross-compile virt-what and make use of it.
In addition to I/O Kit you could use C POSIX functions. Check the man pages.
Because of VMware tools I can copy a string from guest OS to host OS and vice a versa. I want to know how this functionality works ? what VMware performs so that clipboard is shared between two different OS.
Yesterday, I learnt about VARIANT struct in Microsoft COM. VARIANT is like a middle ware on which some engine will run and allow data of one type accessible in other format of some other language.[please correct me if this is wrong or I am not talking right]
So just want to ask, is something like this works in virtual machines ? Because this functionality is so so helpful that I want understand this concept.
I have not tried in virtual box yet but if it supports same functionality then how do they work ? I would like to read about it if any links found.
Since your virtual machine still runs on the true hardware of your host machine it although uses its peripheral devices and hardware.
So vmware or virtual machines in general has to "root" this device to your virtual OS.
So what Vmware (especially VMWARE Tools) does is when you have copied something into your clipboard, to synchronize this data with the second clipboard. So it provides interfaces between your host data like clipboard or date an time and sets it in your virtual OS.
Have a look here:
http://smallbusiness.chron.com/sharing-clipboard-vmware-35825.html
http://www.vmware.com/support/ws55/doc/new_guest_tools_ws.html.
This does not exactly answers your question, but should give some ideas on further research.
If hardware support is a must for virtualization, how can Java Virtual Machines run on machines without support for virtualization ? Or is JVM not a virtual machine ?
A JVM is not virtual in the same sense as a VirtualBox or VMWare virtual machine. It is a 'machine' that implements the Java bytecode, not a virtualized version of actual hardware.
The term-of-art 'virtual machine' was coined a very long time ago for the following scenario:
make up a computer, like Knuth's MIX.
write a computer program that implements the made-up computer.
run programs
When this virtual machine runs, it's a completely ordinary program, running completely in user mode. It needs no special help from the hardware or operating system to work reasonably well. This is especially true of the JVM, since the Java byte code does not deal with low-level hardware I/O or other things which are hard to simulate.
Later, historically, (to pick a particular instance), IBM invented VM/370. VM/370 uses the other sense of the term 'virtual machine'. In this later sense, the hardware and operating system cooperate to allow a single physical machine to host multiple virtual instances of (more or less) the same architecture, in which multiple copies of the whole operating system are written as if they are running on more or less bare hardware. Later, the X86 was designed with features to facilitate this.
So, yes, any virtual machine is making use of some physical hardware, unless you implement it with pieces of paper passed around a table (pace John Searle). But when the virtual machine bears no resemblance to the machine it is running on, then there's no need for special help from the operating system and hardware, and no need for anything as complex as VM/370, or VMware.
If hardware support is a must for virtualization, ...
Let me stop you right there :-)
There is a difference in concept between the JVM (software virtualization) and (for example) a VMWare VM (hardware-assisted virtualization).
The JVM (and other software-based VMMs such as the ones that allow to to emulate x86 on Solaris hardware - I think Bochs and possibly DosBox fall into this category) runs like any other application, using the operating system to gain access to the hardware, or emulating its own hardware purely in software.
VMWare, and the other VMMs optimised for speed, rely on hardware support. In other words, they run on the hardware as if they have full access to the hardware and, only when they try to do something they're not supposed to does the OS captures that attempt and fake it.
That's why VMWare runs so much faster than the software-only emulators. It's because, for the vast majority of the time, it's actually running on the real hardware.
The JVM is a virtual machine, but it doesn't require any additional support from the Operating System. Instead of virtualising instructions for a particular CPU it executes java bytecode.
The JVM is a virtual machine for running Java, in other words it emulates a machine which would be capable of running java. It is a confusing choice of names, but it comes from the general meaning of "machine" not from the more common Virtual Machine meaning.
The JVM, like a regular VM emulates the execution of instructions, but in the case of the JVM the instructions being emulated are Java Instructions, and in the case of a VM they are Hardware Instructions as would be executed by an OS running on the same hardware.
Yes the JVM does access hardware, however this is why you install a MAC or WINDOWS JVM since the instructions are translated by the JVM and acted upon depending on the installation of the JVM, for example, open file dialog on mac opens the mac dialog and windows JVM opens the windows dialog.
So its not being virtualized by the system, but the bytecode is being virtualized by the JVM you installed. It's basically like an application that reads something(bytecode) and does something(access hardware, or other stuff).
It should be noted that nothing stipulates that a JVM does not (have to) have HW virtualization access. There are notable exceptions, but to which the answered poster alluded, few CPs exist that run Java bytecode natively. Maybe someday a Java bytecode HAL or TIMI will be commonplace to put the JVM into the same class as the formalized HW virtualization?