[Petr]

Is anybody able to help me to understand the internal structure of the VXD files?

If I use SOURCER disassembler, I receive the following output (as an example):

21401  CD 20 0001003F			VMMcall	Get_System_Time	; Win-VMM function   fn=1003Fh
	21407  3B D0				cmp	edx,eax
	21409  77 F5				ja	loc_3326	; Jump if above
	2140B  C1 E1 02				shl	ecx,2		; Shift w/zeros fill
	2140E  89 0D 000010E4			mov	dword ptr data_0171,ecx; (010E4=0)
	21414  E4 21				in	al,21h		; port 21h, 8259-1 int IMR

But if I look in the VXD file alone, I see just zeroes instead offsets in mov instructions, i.e. in this example I'd see just:

89 0D 00000000			mov	dword ptr 0,ecx

If I look into the WDF file generated by the Windows Source Preprocessor, I see here:

21410	wd	000010E4

So the preprocessor was able to determine that the double-word on offset 21410 should be overwritten by 000010E4. OK, but where is the information stored? I tried to search for both 21410 and 000010E4 but nothing found.

So where this information is stored and in what format?

Is there any good information source regarding the structure of LE (VXD) files?

Petr

[jimmsta]

I'm very interested in what the VXD files may have to offer, in terms of extensibility.

I did the following google search: "structure of 16bit VXD" (without quotes), and came up with a few pages that offer an insite as to what the structure is...

http://podgoretsky.c...D/vxd-tut7.html
http://www.podgorets...D/vxd-tut3.html

And this site: http://www.tbc.net/~clive/vcomwinp.html has a few decompilers/extracters for Win95 VXD files -- Just a heads up, according to this site, the VxD files can be extracted, and more VXDs hide inside the VXD files stored in the SYSTEM folder... Some sort of microsoft compression scheme is used, probably to keep initial memory usage low at boot time. (or possibly only load code that will fit in conventional memory (?)). This may explain why you can't find the location of the code referenced above.

Be sure to grab all the utilities on that site, as you'll need dumplx to dump out each VXD into a text file (ASM disassembly). It all works out pretty darn well, if I do say so myself.

Hope this helps some. Good luck.

edit2: Hehehe... Our very own MDGx has one of the utils on his site, VxDLib - http://www.mdgx.com/98-3.htm <- Points to the above "and this site:" link.
Also: http://www.helpwithw...iles/vmm32.html - " Now there may come a time, when one of the *.vxd files built into vmm32.vxd needs to be updated, and Win9x provides a very simple means for this. Each system has a Windowssystemmm32 directory. Any *.vxd file in this directory will be automatically loaded and used during Win9X startup, instead of the one in the vmm32.vxd file if it exists in both places. In other words files in this directory take precedence over same files within vmm32.vxd. So when these web sites have you put the individual files in this directory all they are doing is putting a copy of the same code that is already within vmm32.vxd into this directory as stand alone files which will actually cause Win9X to take longer to load. Microsoft says that Extracting system files that are rolled into VMM32.VxD will not increase system performance, once you are started, there will be no difference. The reason for bundling VxD's into VMM32 was to improve system boot time."

So, it seems that the possibiliy that your memory addresses are actually relating to another file is very, very possible, according to this article.

And here's another page with some Win95 vmm32 hacks: http://netweb.usc.edu/yaxu/ISPsoftware/Sha...ok/unauthw.html

And here's a site with some useful VxD hacks: http://www.dcee.net/...ogramm/Windows/

After fooling around with a decompiled VMM32.VXD from a VMWare install of Windows 98SE (No patches), I managed to create some dumplx log files, which are mostly ASM listings of some of the VXD's. Here's a zipped up copy of the log files: http://rapidshare.de...33/vxd_logs.zip

This post has been edited by jimmsta: 25 September 2006 - 10:55 PM

[Petr]

jimmsta, on Sep 26 2006, 04:54 AM, said:

I did the following google search: "structure of 16bit VXD" (without quotes), and came up with a few pages that offer an insite as to what the structure is...

Thank you for your reply jimmsta, btw, LE files are linear executable 32-bit, not 16-bit.

Clive Turvey is author of the SOURCER disassembler that I use and I use his utilities too.

The information I'm looking for is where the data offsets are stored, this knowledge is necessary to patch the VXD files. I was not able to find where in in what format this information is stored.

Petr

[LLXX]

You're looking for the LE/LX file format?

http://www.textfiles...RMATS/lxexe.txt

[Petr]

LLXX, on Sep 26 2006, 08:24 AM, said:

You're looking for the LE/LX file format?

http://www.textfiles...RMATS/lxexe.txt

Thank you for the link LLXX. It seems the internal structure of VXD files is much more complex than I expected. It looks like "Fixup Record Table" could be the right place but I have to look at it much deeper later.

Petr

[Ninho]

Petr, you are misguided, vxd's are 16-bit code. You are excused : I see this misconception all the time (including in the Wikipedia. Don't believe everything you read on the 'net:)

Basically, Windows 9x is a 16-bit OS which runs 32-bit apps. The system code is roughly half 16-bit, half 32-bit. The virtual device drivers (vxd's) are 16-bit code (of course, they can and do manipulate 32-bit DATA, but that's another story).

This is why they use the LE format, not PE !
This is also why your disassembler shows you garbage. You need to instruct the disassembler to show the code as 16-bit, or use another disassembler.

Yes, I have written quite a few vxd's myself (in MASM)...

HTH

--
Ninho

[Petr]

Ninho, on Sep 26 2006, 11:09 AM, said:

Petr, you are misguided, vxd's are 16-bit code.

I don't know, Microsoft states in the Resource Kit:

Quote

The Virtualization Driver

A virtualization driver (VxD) is a 32-bit, protected-mode driver that manages a system resource, such as a hardware device or installed software, so that more than one application can use the resource at the same time. VxD refers to a general virtualization driver; the x represents the type of device driver.

My disassembler (Sourcer) works correctly because it uses Windows Preprocessor that defines all necessary things.

My problem is with the file itself, I want to modify the code and I don't know where the offsets are stored, I have to study the LLXX's document.

Petr

This post has been edited by Petr: 26 September 2006 - 07:17 AM

[LLXX]

Ninho, on Sep 26 2006, 04:09 AM, said:

Petr, you are misguided, vxd's are 16-bit code. You are excused : I see this misconception all the time (including in the Wikipedia. Don't believe everything you read on the 'net:)

Basically, Windows 9x is a 16-bit OS which runs 32-bit apps. The system code is roughly half 16-bit, half 32-bit. The virtual device drivers (vxd's) are 16-bit code (of course, they can and do manipulate 32-bit DATA, but that's another story).

This is why they use the LE format, not PE !
This is also why your disassembler shows you garbage. You need to instruct the disassembler to show the code as 16-bit, or use another disassembler.

Yes, I have written quite a few vxd's myself (in MASM)...

HTH

--
Ninho

You couldn't be more wrong. VxDs can contain both 16-bit realmode *and* 32-bit protmode code in different sections. Disassemble a driver like the ESDI_506 I patched for Enable48BitLBA and you'll see what I mean.

...and Petr, have you tried IDA? It's *much* better than Sourcer.

[Petr]

LLXX, on Sep 27 2006, 04:13 AM, said:

...and Petr, have you tried IDA? It's *much* better than Sourcer.

I have heard this but I use Sourcer for almost 20 years already.... I even tried to use IDA many years ago but it looked very strange and confusing to me. Do you know about good tutorial how to use it?

Petr

This post has been edited by Petr: 26 September 2006 - 11:54 PM

[Ninho]

LLXX wrote : You couldn't be more wrong. VxDs can contain both 16-bit realmode *and* 32-bit protmode code in different sections.

Yes, that is why the LE/LX format was brought to Windows (from OS2).

Indeed I was coming here to amend my statement so as to state what you say above clear. I erred yesterday, my feeble excuse is I haven't put my hands into dirty Windows 3/9x system code since ca 2000. Again, believe me or not, I disassembled lots of vxd code and assembled mine in turn, *and* of course I studied the DDK and VMM functions. Not a pleasant sight altogether ;=)

@Petr: the best way to 'see' vxd code in action is with the help of a kernel debugger, SoftICE, TRW or Microsoft's own. There used to be a specialised disassembler for LE/LX, by an author who also wrote a PE disassembler. Edit : I'm being an old fool again, reading the thread shows you must have got all the toolz & what you were really after was the LE file layout ;=) Best wishes for success !
--
Ninho

This post has been edited by Ninho: 27 September 2006 - 02:28 AM

[LLXX]

Petr, on Sep 27 2006, 12:53 AM, said:

LLXX, on Sep 27 2006, 04:13 AM, said:

...and Petr, have you tried IDA? It's *much* better than Sourcer.

I have heard this but I use Sourcer for almost 20 years already.... I even tried to use IDA many years ago but it looked very strange and confusing to me. Do you know about good tutorial how to use it?

Petr

I learned IDA by just exploring the different menus and key combinations... I know the documentation is rather terse but it's really not of much help at all. Supposedly the newer versions have a better Windows GUI but I've always stayed with v3.6...