Geoff Chappell - Software Analyst
Installing the Internet Information Services (IIS) gets you a Default Web Site. This is a fully functional web server. It can be accessed from the same machine using the URL http://localhost and from all machines on the intranet using http://computername. With a DNS server or just a HOSTS file, you can expose the Default Web Site across your intranet under any domain names that you care to invent. You can even expose it to the actual Internet.
IIS allows for more than just the Default Web Site. Of course, each additional web site (also called a virtual web server) must have a unique identity on the network. Short of getting multiple IP addresses for the one machine or of expecting users to include a port number in the URL, this means that each different web site has its own host header name.
In Windows Server 2003 and Windows 2000 Server, creating additional web sites is important enough to warrant user-interface support in the Internet Information Services (IIS) Manager:
The selected menu invokes a Web Site Creation Wizard which takes you through a series of property sheet pages:
It really couldn’t be much easier, but for those who don’t already know what to do, the Help Topics for the IIS Manager have several relevant pages, including a section that is titled Hosting Multiple Web Sites on a Single Server.
This user-interface support is not present in Windows XP and Windows 2000 Professional. The context menu for the Web Sites folder has nothing for creating a new web site. Indeed, it has no submenu for making a New anything:
The product documentation, which is found in these versions by browsing the Default Web Site (specifically in a virtual directory named IISHelp), says not exactly unambiguously that the product is limited to one web site. For instance, under Frequently Asked Questions, the whole answer to “How do I create multiple Web sites?” is:
Windows XP Professional with IIS can host one Web site and one FTP site on a single computer. If you would like to host multiple Web sites or FTP sites on a single computer, consider upgrading to a Windows server product.
Yet many pages in the product documentation are written as if multiple web sites can exist, e.g., because grammar suggests that the reader may have a choice of web sites to operate on. One page of the product documentation even presents the syntax of an administration script, named MKW3SITE.VBS, for creating a web site.
In fact, the Windows client products such as Windows XP and Windows 2000 Professional are not constrained to having just the one web site. The only constraint is that at most one web site may be running at any one time. If you know how, you can create as many web sites as you want. What you can’t do is use them simultaneously.
This article addresses both issues. The means of creating a web site are obscured, but the user-interface support is actually present in the executables and can be restored. Being unable to start a second web site without stopping the first can also be patched away.
That IIS allows creation of multiple web sites on the client products is really no secret. That the documentation has a page for the MKW3SITE script may look like an editing oversight for Windows XP, given that no such script is supplied with the product, but it’s no oversight for Windows 2000 Professional. The MKW3SITE script is included with Windows 2000 Professional and it works. For Windows XP, with no MKW3SITE script, you can get the same effect from several executions of the more general ADSUTIL, first to create the web site and then to set its properties.
For most users, these scripts would probably be enough facility. It’s more cumbersome than you might like, but you take what you can get. Microsoft apparently does not want its customers hosting multiple servers without upgrading to a server product, and Microsoft certainly has removed all plain-language encouragement, but at least the feature remains and at least it’s not buried in anything more obscure than a script. If you want the details, read the script.
The interest here is instead with the realisation that all the resources that are needed for the user-interface support, i.e., for the New Web Site menu and for the property sheets of the Web Site Creation Wizard, are present in the client versions of INETMGR.DLL and so too is all the code that supports this user interface. It just doesn’t run, but perhaps it can be made to. Then, the context menu for the Web Sites folder would have a submenu named New, from which you could create a new web site easily and naturally:
It turns out that Microsoft has defined a set of what are apparently called server capabilities. These are determined by INFOCOMM.DLL, running in the INETINFO.EXE process, and are set into the IIS metabase as an undocumented entry (specifically, with the identifier 1103). The value is a dword of bit flags. INFOCOMM has hard-coded values for different combinations of platform and product type:
platform is NT and product type is either domain controller or server | 0x00013BBF |
other product type on NT platform | 0x00013162 |
anything else | 0x00000062 |
Only one variation to this hard-coded initialisation is known: the 0x0400 bit is added if the registry key HKEY_LOCAL_MACHINE\Software\Microsoft\FrontPage\3.0 can be opened for read access.
The capabilities bit that permits INETMGR to show the New menu for Web Sites and FTP Sites is 0x80. Restoring the New Web Site menu is therefore a matter of either:
Both work. Patching INETMGR was what I did for my own purposes in January 2007 (when building a new website from the contents of another), but I think on reflection that patching INFOCOMM is better.
In all the INFOCOMM versions listed below, the hard-coded value that must change is 0x00013162 and the instance that is wanted is in an instruction that has either of the following forms:
Opcode Bytes | Instruction |
---|---|
C7 45 xx 62 31 01 00
|
mov dword ptr [ebp-d8],00013162h
|
C7 85 xx xx xx xx 62 31 01 00
|
mov dword ptr [ebp-d32],00013162h
|
Whether the instruction has an 8-bit or 32-bit displacement, only the one byte of immediate data has to change, from 0x62 to 0xE2:
INFOCOMM.DLL Version | Package | File Offset |
---|---|---|
5.0.2185.1 | Windows 2000 | 0x0001C0D0 |
5.0.2195.1600 | Windows 2000 SP1 | 0x00015BCB |
5.0.2195.4430 | Windows 2000 SP2 | 0x00017E5E |
5.0.2195.5437 | Windows 2000 SP3 | 0x00018123 |
5.0.2195.6709 | Windows 2000 SP4 | 0x00017B99 |
6.0.2600.1 | Windows XP | 0x00014AC6 |
6.0.2600.1106 | Windows XP SP1 | 0x00014B24 |
6.0.2600.2180 | Windows XP SP2 | 0x00015D88 |
6.0.2600.5512 | Windows XP SP3 | 0x00015D28 |
6.0.3790.0 | Windows Server 2003 | 0x000141DD |
6.0.3790.1830 | Windows Server 2003 SP1 | 0x00014E29 |
6.0.3790.3959 | Windows Server 2003 SP2 | 0x00014A4D |
Of course, the patch is of no value if you are running a server edition of Windows, but I include locations for Windows Server 2003 because Windows XP and Windows Server 2003 have the same major and minor version numbers for INFOCOMM and it does not seem impossible to me that an INFOCOMM intended for Windows Server 2003 will end up running on at least some installations of Windows XP.
If you are not completely certain how to interpret file offsets, to check the bytes and to edit them, then do not try to patch the file. Even if you think you know what you are doing, please take care to work on a copy. Use some command such as fc /b to compare your patched copy with the original, and verify that you have changed only the expected bytes.
Recent versions of Windows ordinarily protect sensitve executables from corruption, so that they are automatically restored from a cache (or from your installation media, which you may be asked to insert). You can disable this feature and copy your patched INFOCOMM.DLL to both the INETSRV directory and the cache, but I recommend strongly that you do not.
The best way to install a patched executable that is otherwise subject to Windows File Protection is to copy it into place using another operating system. If you do not already have another Windows installation in a multi-boot configuration, then boot the Recovery Console. This is available on your Windows installation media, but you might do well to install the Recovery Console onto your hard disk, as a multi-boot option. If you do not know how to work the Recovery Console and cannot make sense of Microsoft’s directions, e.g., in Windows Help and Support, then do not try using it.
As noted above, when Microsoft says that Windows client products such as Windows XP can host only one web site, the actual behaviour is that additional web sites are creatable but no more than one may be running at any one time. INFOCOMM.DLL has a class that represents any IIS service and this class has a member function that counts the running instances of that service. This function may fairly be represented in C++ as:
BOOL IIS_SERVICE :: RecordInstanceStart (VOID) { LONG count = InterlockedIncrement (&m_Count); if (g_PlatformType != 2 && count > 1) { InterlockedDecrement (&m_Count); return FALSE; } return TRUE; }
in which 2 means that the platform is NT and the product type is domain controller or server. To allow that the count of running instances may exceed 1 is therefore a matter of defeating either of the tests. This is most easily done by changing the if block’s first jump from conditional to unconditional.
In all but one of the known builds, the patch site is in the one occurrence of the following sequence:1
Opcode Bytes | Instruction |
---|---|
83 3D xx xx xx xx 02 74 xx 83 F8 01 7E xx |
cmp dword ptr [variable],2
je @f cmp eax,1 jle @f |
Only the one byte has to change: from 0x74 to 0xEB.
More generally, the patch site may be located easily since the RecordInstanceStart function is exported by name and is therefore readily found with a debugger or in a disassembly such as prepared by Microsoft’s DUMPBIN program. I recommend strongly that even for the builds in the following table, you should look for yourself to see that what you intend to patch actually is in the RecordInstanceStart function. If this is beyond your technical competence, then you ought perhaps not be patching executables.
INFOCOMM.DLL Version | Package | File Offset | Remarks |
---|---|---|---|
5.0.2185.1 | Windows 2000 | 0x00002F9B | change 0F 85 to EB 04 |
5.0.2195.1600 | Windows 2000 SP1 | 0x00015E72 | |
5.0.2195.4430 | Windows 2000 SP2 | 0x00018105 | |
5.0.2195.5437 | Windows 2000 SP3 | 0x000183CA | |
5.0.2195.6709 | Windows 2000 SP4 | 0x00017E40 | |
6.0.2600.1 | Windows XP | 0x00013E9A | |
6.0.2600.1106 | Windows XP SP1 | 0x00013EF8 | |
6.0.2600.2180 | Windows XP SP2 | 0x0001509C | |
6.0.2600.5512 | Windows XP SP3 | 0x0001503C | |
6.0.3790.0 | Windows Server 2003 | 0x000135B8 | |
6.0.3790.1830 | Windows Server 2003 SP1 | 0x00014168 | |
6.0.3790.3959 | Windows Server 2003 SP2 | 0x00013D8C |
With two bytes changed in one executable, it becomes possible to create multiple web sites on Windows XP or Windows 2000 Professional and to have them all running simultaneously:
But are you permitted, whether by a supposed agreement with Microsoft or by the law of the land, to edit Microsoft’s executables for such an effect? And am I permitted to tell you how?
At this website, there are a few other pages that direct you to patch an executable in order to fix a bug, especially a bug that Microsoft does not acknowledge or will fix for you only by the time-honoured abuse of leaving you to upgrade Windows (for a fee, of course). See for instance Missing Icons in Notification Area. On no such page do I mean to convey the slightest sense that the obstacles to fixing a fault by patching an executable are anything other than technical. I don’t begin to know what might guide a court, but I would find it incredibly perverse that a product can be sold with an enforceable prohibition on fixing its faults (or anything that the purchaser reasonably considers to be a fault).
The patching on this page is quite different. There is no bug to correct. Instead, means are found to enable a feature which Microsoft chose to disable in (but not remove from) some of Microsoft’s products. Not incidentally, the products in which the feature is disabled sell for (markedly) less than the products in which the feature is enabled. In uncovering the feature, there is an element of taking something that has not been paid for. Yet you don’t have to browse much of this site to realise that if there’s nothing here about cracking software it’s not because of technical incapacity. It’s because cracking software is not what I do. So, why do I make an exception now for what is, really, only a small feature?
Microsoft’s documentation is far from unambiguous that the feature is disabled in the affected versions. The terms of the so-called licence agreement do not explicitly limit the number of simultaneously running web sites. Some text in the IIS documentation says something about hosting only one web site, yet Microsoft itself supplies a script (or two, depending on the product version) that will create extra web sites. Where a search of product documentation, the MSDN Library or Microsoft’s website finds pages that talk of creating web sites but do not list Windows XP among the applicable products, how is any reader to know whether this is just another of Microsoft’s all-too-typical oversights. After all, some of these pages, presumably just from being old, don’t list Windows Server 2003 either. Some other pages that do list Windows XP as an applicable product talk as if the user may have a choice of web sites, such that it’s only inevitable that readers may then waste time wondering how to create more web sites. A sprinkling of asterisks for fine print along the lines of “not available on X, Y and Z models” is a familiar sight in manuals for washing machines, and even of much lowlier consumer goods, but is apparently too much trouble for Microsoft.
So, in case it’s not clear yet, let me stress: had Microsoft stated plainly, clearly and unambiguously that IIS in Windows XP is not licensed to host more than one website, then this article would not exist.
If you think it unethical to patch away a check for the product type or to patch in a different hard-coded default, then don’t apply the patch. I don’t mean to encourage you one way or the other, but I do mean to encourage you to think about the games that software manufacturers play with you—and to begin that thinking, you need to know what those games include.
[1] I am grateful to Alan Feldman for pointing out to me that the JE and JLE instructions had been given incorrectly as JNE and JL. What sort of editing mistake produced that, I can’t think, and I am now in fear that the reason many similar, or worse, mistakes are not discovered every other day is just that nobody cares enough to tell me.