but… But… I don’t think Virtual Device Drivers are what you think they are. Or were. They’re an obsolete way of supporting a small, tiny, sunset of devices for use by old MS DOS style programs. They were never very useful, and have nothing to do with… Anything, really.
I’m done. Good luck doing whatever. If the discussion starts sounding too much like malware, I reserve the right to pull the plug.
> The point is to create a variety of loadable exploits that are interpreted by a signed driver.
Well, you seem to be of too high opinion on the OP’s level of knowledge/skills/understanding/etc…
To me the OP sounds more of someone who just encountered the word “virtual” so that he goes on asking about the topics ranging from Win95 virtual DOS devices and 8086 virtual mode to Java and .NET VMs, without rmaking any distinction between these things as long as the word “virtual” is used with them. I guess the only thing left is to add the virtual reality to this salad…
My level of knowledge/skills/understanding/etc… are definitely lower than of the people around here.
I have observed a product actually install - the obselete Win95 VxD on win7 and use it. I dont know why/how/etc… This has caught my attention. I dont believe this is possible without virtualization. The implementer has actually created virtual reality.
My level of knowledge/skills/understanding/etc… are definitely lower than of the people around here.
I have observed a product actually install - the obselete Win95 VxD on win7 and use it. I dont know why/how/etc… This has caught my attention. I dont believe this is possible without virtualization. The implementer has actually created virtual reality.
Not really. The problem is that the term “virtualization” has many
meanings.
For example, look at the “wine” package, that allows Win32 executables
to run on Linux. They have provided libraries that supply Win32 entry
points and translate those to Linux system calls. While it is running,
it is a Linux process running at full processor speed that happens to
have special libraries. That is one form of virtualization.
At the other end, you have products like Bochs or Qemu, which provide
instruction-level simulation of many different processors. That is
another form of virtualization.
In the case of a VxD, it would be the first kind of virtualizaiton.
Virtually all communication between VxDs and between a VxD and the VMM
manager was conducted through a software interrupt (INT 20). As long as
the Win 7 product provides a handler for INT 20 that simulated what VMM
would do, you could run the VxD.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
My level of knowledge/skills/understanding/etc… are definitely lower than of the people around here.
I have observed a product actually install - the obselete Win95 VxD on win7 and use it. I dont know why/how/etc… This has caught my attention. I dont believe this is possible without virtualization. The implementer has actually created virtual reality.
> Does that mean as follows: Register an interrupt handler for INT 20 and execute an VxD.
Nope - after all, this is indows so that you are not allowed toregister your custom interrupt
handler stubs. Instead, you have to make VxD believe that it calls system-provided INT 20 handler.
This can be done in different ways,depending on how VxD links to libraries that actually issue
INT 20 instruction. If they link dynamically all you have to do is to provide your own custom libraries that Vxd links with, i.e do things the way Tim explained. If they link statically you need something more elaborate.
For example, you can use debug API so that the process that executes VxD code runs under the control of your “debugger”, i.e. emulator. Then you can scan the code, locate all instances of
INT 20 instruction, and replace them with someting else (for example INT3 one) before allowing the target process to run. When this instruction gets executed, the system witll freeze the target process and transfer control to your “debugger” that controls it. At this point your “debugger”/emulator will read the target process, do whatever it has to do to emulate the target call, and allow the target process to continue.
In either case, this is 100% userland solution wih no kernel code anywhere in sight…
Does that mean as follows: Register an interrupt handler for INT 20 and execute an VxD.
Well, sort of, but neither of those things is as straightforward as you
make it sound. In the NT kernel, you can’t just arbitrarily grab INT
20. There’s a certain amount of magic involved in installing a handler
for a software interrupt. Plus, the interrupt handler you install has
to be able to handle all of the VMM core requests that your VxD is
likely to make. The VMM in the 16-bit Windows systems was quite a
sophisticated beast. It was an operating system in itself – one in
which Windows happened to be one of the programs it ran.
Plus, VxDs are LE-format executables, not PE-format executables. That
means they were created with the old segmented linker. Thus, you can’t
rely on operating system services to load the binary. You would have to
write your own VxD loader.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.