Single-image download and execution with no setup program has been a hallmark of almost all of the tools that Bryce and I write and distribute on Sysinternals. I think most visitors agree that it’s more convenient to download a 200 KB ZIP file, extract its contents and execute a utility than to download and execute a 2 MB installer, in the process adding more clutter to your Start menu, before you can gain access to the tool only by navigating through that cluttered start menu to find it. And in the unlikely event you don’t want to use a tool any longer uninstalling a Sysinternals tool usually means just deleting it. User-preferences in the user-profile portion of the Registry (HKCU) might get left behind, but a lot of uninstall programs leave behind more than a few hundred bytes of data.

Unfortunately, the requirements faced by many tools of supporting 3 major lines of Windows operating systems – Windows 9x (believe it or not, if I post a tool that breaks compatibility with Windows 95 by using an API introduced in a newer version of Windows I hear about it immediately), Windows NT and Windows 64-bit – and several minor variants of each line makes delivering a tool as a single universal executable a challenge. Besides finding backward-compatible ways to accomplish what newer Windows APIs might make trivial, the tools that require support from a device driver or that require a native 64-bit image in order to work on 64-bit Windows face the biggest single-image delivery hurdle.

When we released the original versions of tools like Filemon and Regmon back in 1996 there were two downloads: one for Windows 95 and one for Windows NT. Each download file included an executable and driver where the executable was identical to both, but the driver specific to the operating system since the driver architecture for most types of Sysinternals drivers is totally different for Windows 95 than Windows NT. I wasn’t totally pleased with this arrangement since the connection between the driver and executable files wasn’t obvious to most people and copying the tools between systems meant having to remember to copy both files.

Then in March 1998 I came across an interesting article by James Finnegan in Microsoft Systems Journal (now MSDN Magazine) that describes how to embed a driver as a resource in a host executable. When it starts the host executable extracts and installs the driver. I immediately began using the technique to pull the drivers into the executables. With James’ trick I could post one Filemon download consisting of a single executable that contained within it both the Windows 9x and Windows NT drivers. At runtime the executable detects the Windows version and extracts and installs the appropriate driver.

Over the last several years I’ve refined James’ code to be even more efficient, not even creating a Windows service to host the driver, but rather loading drivers directly using the undocumented NtLoadDriver API. To handle cases where you run the executable from removable media or a network share the tools try to extract their drivers to \Windows\System32\Drivers. If that directory is inaccessible, which would be the case if you booted Windows Preinstallation Environment (WinPE) off a CD, they fall back on extracting to the same directory in which the executable resides. A further refinement is made possible by the fact that Windows reads driver images entirely into memory and so never needs to reference driver images after loading them. Sysinternals tools take advantage of this by deleting their drivers immediately after loading them.

Here’s a Filemon trace of Regmon’s startup on Windows XP that shows Regmon extracting the driver to \Windows\System32\Drivers and then deleting it after it has installed the driver in memory:



As the years progressed the download executables for several tools grew to include more than two drivers. For example, the Registry monitoring architecture is different on Windows Server 2003 than on previous versions of the Windows NT line. That means that after Server 2003 released Regmon’s executable had three drivers stored within it.

Then with 64-bit Windows (the AMD64 variety of course – you might have noticed that there’s little support for Itanium, which reflects my belief, and I think that of others, including Microsoft and Dell, that Itanium has a limited future, one only guaranteed so long as there are no 64-way Opteron systems) I faced a new challenge: how could I continue to deliver single-image downloads for utilities like Filemon, Regmon, Process Explorer, and LiveKd, that require a native 64-bit executable in order to run on 64-bit Windows? Most 32-bit applications run fine on 64-bit Windows, but because of the pointer size difference it takes a 64-bit process to query the virtual memory of a 64-bit process.

The solution I came up with is to store a utility’s 64-bit version within its 32-bit image. When you run the 32-bit executable it detects the Windows version, and if it’s running on 64-bit Windows, extracts and executes the 64-bit image, waits for the 64-bit process to exit, and then deletes the 64-bit image. Here’s a Filemon trace of the 32-bit Process Explorer extracting the 64-bit version:



And here’s Process Explorer showing the process tree that graphically shows the relationship between its own 32-bit and 64-bit images:



As a result of all the different Windows versions we support the Regmon executable now has the following images embedded within it:
  • The 32-bit executable
  • The 64-bit executable
  • The 64-bit driver
  • The Server 2003 driver
  • The Windows NT, 2000, XP driver
  • The Windows 9x driver
Even with all that Regmon weighs in at only 415 KB: the 32-bit image by itself is only about 150 KB in size and each driver version is under 50 KB in size.

I think most of you will agree that a 180 KB zipped download of Regmon that requires no installation and that can be simply copied from system to system is preferable to the “best practices” alternative: a 2 MB MSI download that takes up to a minute to install just to get a 150 KB executable and 50 KB driver onto a system.

Originally by Mark Russinovich on 9/19/2005 7:24:00 PM
Migrated from original Sysinternals.com/Blog

# re: Multi-platform Images

Ahh... This article makes me happy.

9/19/2005 8:07:00 PM by Anonymous
# re: Multi-platform Images

I don't know what others think, but I wish you did have a traditional Windows installer. Not one per tool, but a master installer. I configure a lot of systems and I always find myself going to your web site and pulling down 4 or 5 tools, extracting them, etc. I even think a program group is useful!

9/19/2005 8:45:00 PM by David Douglass
# re: Multi-platform Images

Yeah a zip file of all your tools combined would be great ;)

Nice post. Thanks

9/19/2005 11:58:00 PM by Anonymous
# re: Multi-platform Images

We find the tools so valuable that we package them in a GPO deployable MSI with Wise Package Studio. Our techs can't be without these.

9/20/2005 12:32:00 AM by Anonymous
# re: Multi-platform Images

Having read the terms of use in your products readme files, I don't package and deploy them. However I do have a copy on CD I carry with me for my own use. And I try and keep it more or less up to date.

"You may not distribute %application name here% in any form without express written
permission of Mark Russinovich. "

I agree that no installer is neccessary, if someone volunteers their time and resources to supplying this service for you then fine. But I for one don't want to add any time load to you at all as I would prefer the time is spent adding whatever you want to add next.

Thanks for showing us how you did the driver. I don't understand it, but its very interesting nonetheless.

9/20/2005 12:52:00 AM by rivet
# re: Multi-platform Images

I use a lot of your tools and I really do like the lack of any need for registration (like when I want to not install something on a productionmachine) etc, but I'd still prefer an MSI, the 150K download you mention might be 300K as an MSI not 2 meg! It is also quicker to install an MSI than a zip (and installation is easier to automate).
The shortcuts (or lack of) are a killer. It taked me time to do and I always lose them!
It is possible to do an administrative install of the MSI to extract contents or as both MSI and zip versions could be automatically generated in a make file, why not do both!

Someone (rivet) mentioned helping create installer(s), my guess is that's not the issue but I can set them up if thats what you want..

My 2 cents worth,
Dennis

9/20/2005 2:54:00 AM by Dennis Bareis
# re: Multi-platform Images

Can we have a little bit more information about undocumented NtLoadDriver() ?

9/20/2005 3:51:00 AM by Anonymous
# re: Multi-platform Images

I also find the current installation system (single executable) cumbersome.

Instead of an installer launching automatically, I have to unpack the ZIP file.

Instead of the installer creating a shortcut somewhere that I can access easily, I have to launch a Run window each time and type in the location of the executable manually.

If I don't want to launch it manually, I have to open Windows Explorer, find the executable, and create the shortcut manually. It's a pain, and it needs to be done on every system I use Sysinternals tools on. (Don't get me wrong - the tools themselves are wonderful. :) )

It's possible to combine the two approaches. Create a simple custom installer which will contain the payload executable as a resource. It should ask for an installation directory to unpack into (a default should be provided so that most people will just have to click OK). It should have a checkbox whether to create shortcuts in Programs (should be checked by default). That's it.

9/20/2005 5:37:00 AM by Anonymous
# re: Multi-platform Images

I forgot to mention that another reason we don't go with MSI's is that the installer service is not natively present on older versions of Windows.

Here's the prototype for NtLoadDriver.

9/20/2005 6:20:00 AM by Mark Russinovich
# re: Multi-platform Images

I find it irritating that people would whine about a break from Windows 95.

9/20/2005 6:40:00 AM by Anonymous
# re: Multi-platform Images

I like the simple way of downloading a ZIP an extracting it where I want. On my work we have a Shared Directory on the network which contains all kind of tools and utillities, like MS Rescource Kits, Sysinternals tools, and so on.

Trough the logon script we add this directory to the path and when I need a tool I just press Winddows Key+R and type the name of the executable.

9/20/2005 7:42:00 AM by Joop
# re: Multi-platform Images

I'm frensh, sorry for my English.

People complains about having to unzip files instead of launching an installer.

I just do a simple thing : I have a folder on my USB key where my favorites sysinternals tools are unzipped.

So, I plug the key on a machine, and just have to navigate to the folder an launch the .exe
No need for Winzip or other archive tool ...
So simple ...

9/20/2005 7:42:00 AM by Bill2
# re: Multi-platform Images

Thank you for the article, Mark!

A month ago I thought about writing a letter to explain that technique. Until last week ... I had some free time and peeked into Process Explorer to see what's happening there and … I found it. The only point that looked to me strange was the call to IsWow64Process(). That gives you the answer whether we are running on 64bit OS or not, but will embedded image run on Itanium? I’d like to see your comment about this.

In addition to the above discussion: The Sysinternals Tools are GREAT with no doubt at all!!! Should they have installers or not? It depends… On my computer I prefer to install them, and from time to time to update all of them with one click. But if I have to troubleshoot my friend’s computer I prefer not to leave anything because he would wonder what is this and why it wasn’t there before.
Looking at lightweight MSI package creation you can consider WIX toolset http://sourceforge.net/projects/wix/ I can help with it, if you like. Of course there is no native support on Win95/98 for MSI, but could use the zipped version or probably have Office on the computer that already installed MSI.

9/20/2005 8:50:00 AM by Toma Bussarov
# re: Multi-platform Images

Sometimes installation saves a lot of trouble, Mark :)
If you have installed Paint Shop Pro on your computer you would not get those Explorer hangs :)

9/20/2005 8:54:00 AM by Anonymous
# re: Multi-platform Images

Mark,

How exactly are you packing everything up in the .exe?

9/20/2005 9:21:00 AM by Anonymous
# re: Multi-platform Images

Simple, see LoadResource and related functions in MSDN Library.

9/20/2005 10:03:00 AM by Anonymous
# re: Multi-platform Images

Mark,

I have your tools in my general util dirs and I'm using them daily. Upgrading them is a snap from the .zip files (I use Far Manager). Moving them to other computers or network shares is way easier then having to use an installer on every computer. So I totally agree with the current approach.

Installers cover things, you never know what gets put where, and it's especially impractical for command-line tools. Still if someone needs it, there are free tools to create (non-distributed) custom installers (NSIS, Innosetup, WIX) quite easily.

9/20/2005 10:28:00 AM by vszakats
# re: Multi-platform Images

Keeping it simple is best.

The lightest footprint on my client machines, the better. If it's going to mess with the configuration of the install target - particularly in a Configuration-Managed environment, then that's not good.

I much prefer to keep these tools on a CD, or floppy, to bring to my target machines when there's an issue that needs to be looked into.

9/20/2005 11:13:00 AM by Anonymous
# re: Multi-platform Images

>>I don't know what others think, but I wish you did have a traditional Windows installer....

>>Yeah a zip file of all your tools combined would be great...

what stops you from doing that your selves?

9/20/2005 11:13:00 AM by BlackTigerX
# re: Multi-platform Images

I can see some downsides. What's the cost of this in terms of loading time and memory footprint?

Certainly the process of extracting/installing/deleting takes extra time; time the user has to incur every load time. (vs a longer install/download time)

The 64bit scheme is a bit worse - load 32 bit exe, extract 64 bit exe, load 64 bit exe, extract drivers, install driver, delete driver, wait for shutdown, delete 64bit exe.

If you're jumping from machine to machine this is well worth it! If you are constantly reloading a tool on one PC, maybe it's not the best idea? (Process Explorer, for example, could fall into that category).

9/20/2005 11:39:00 AM by Mike Weiss
# re: Multi-platform Images

One thing that bothers me (slightly) is that the zip file for each tool contains a README.TXT. It would have been easier if it was named after the tool itself, because now I have to rename all the README's if I want them in the same place.

Thanks!

9/20/2005 11:55:00 AM by Anonymous
# re: Multi-platform Images

With an MSI, doesn't windows need to keep a copy of the original msi around? If you get around to deleting it from the local settings (or wherever), woe be unto you who wants to uninstall that software.

9/20/2005 12:12:00 PM by Poopy McPoop
# re: Multi-platform Images

Okay maybe an installer option might be nice. But definately, positively, absolutely, do not stop offerring standalone EXEs!!!!
The lighter the foottprint, the better - the only thing better and lighter would be assembly but that takes too long to code. Your tools are the greatest - I knew they loaded drivers and now I know how. Thanks for the insight into the internals of systinternals tools!
Attendee of your class in Bellevue, last year.
Keep up the good work.

Mike

9/20/2005 12:37:00 PM by Anonymous
# re: Multi-platform Images

Mark,

I don't suppose you would want
to post the code you use to extract
and run .exe and .sys files from resources.

This seems straight forward, but copy and paste is easier.

9/20/2005 12:54:00 PM by Anonymous
# re: Multi-platform Images

{believe it or not, if I post a tool that breaks compatibility with Windows 95 by using an API introduced in a newer version of Windows I hear about it immediately}

He-he autoruns.exe v8.13 no starting up on windows 95
(may be not OSR2 his...) OS tell no ws2_32.dll present :)

i know need upgrade winsock but...

9/20/2005 1:24:00 PM by Zeroes
# re: Multi-platform Images

I prefer ZIP files over MSI installers. It's very easy to unzip them to the %windir% directory and they can be executed anywhere (no need to tweak the PATH variable)

I hate it when microsoft releases their resource kit tools in MSI packages!

If you ever decide to offer MSI files, please keep also the ZIP files available!

9/20/2005 4:32:00 PM by Anonymous
# re: Multi-platform Images

Great tools by Sysinternals, I just put them in a directory that is in my searchpath so I can run them from the command line or Run option from the Start Menu. But for everybody that wants easy clickable shortcuts in the Start Menu for these tools: I have put together a little utility that can do just that. Based on entries in an INI file the utility creates shortcuts. Download MakeShortcuts. Steve

9/20/2005 5:15:00 PM by Steven van Loef
# re: Multi-platform Images

I use NSIS for all my installers. Has a very small footprint, which it sounds like you'd appreciate Mark. :) And it works with Windows 95. ;)

http://nsis.sourceforge.net/

9/20/2005 10:39:00 PM by Anonymous
# re: Multi-platform Images

The tools from Sysinternals are second to none. Any complaints about lack of installers should be left at the door. It seems many people don't read (or probably abide) by the 'no redistribution' license that the tools are released under.

9/21/2005 5:00:00 AM by Anonymous
# re: Multi-platform Images

I like the single EXE format - good for running from a share. There's definitely something to be said for applications that don't need to be installed/uninstalled, especially if you're going to use them to debug slightly dodgy machines.

If .exe size gets too bad you could pack them with UPX or similar. Actually, you could make the distributed EXE file a shell that just inflates the bits it needs to a temporary directory with zlib.

9/21/2005 8:35:00 AM by Anonymous
# re: Multi-platform Images

Mark,

I appreciate your justification for the simple approach, but count me in the installer lovers crowd. I appreciate the manageability and discoverability over the 2Mb difference in file size and delayed gratification of having to go through a set of installer screems before running the utility. Any chance we could convince you to offer an MSI as an option?

In any case, thank you for making these available!!!

9/21/2005 10:55:00 AM by Michael Teper
# re: Multi-platform Images

I love the tools, and I do prefer the non-installer option.
This is what I try to do for all the small tools I write. And for settings I use .ini files in the same folder with the application. This way I do not leave traces in the Registry and I can also carry my preferred configuration with me.

9/21/2005 10:35:00 PM by Mihai
# re: Multi-platform Images

Nice article, I only superficially understand it, but very clever workings.

I find the sysinternals tool invaluable and really appreciate the lightness of the single .exe

I tend to have the ones I use in a single directory and add that directory to my patch, then create a keyboard shortcut to open up a command window - even to launch the gui based tools

keep 'em light, keep 'em single .exe's

nice one :)

9/22/2005 10:49:00 AM by cw1972
# re: Multi-platform Images

"add that directory to my patch"

obviously I mean path, dunno how the 'c' got in there :)

9/22/2005 10:51:00 AM by cw1972
# re: Multi-platform Images

technically... you could probably embed a dos stub too ;)

9/23/2005 4:00:00 PM by Anonymous
# re: Multi-platform Images

How about a download manager to keep them all up to date :) With connections being as they are these days, it wouldn't take long to download the whole lot.

9/23/2005 6:24:00 PM by Anonymous
# re: Multi-platform Images

The driver installation technique is very neat... but... Why doesn't Windows complain about the driver "not being signed"?

Or, are the drivers signed?

I thought that every driver installed would force Windows to display the "Driver information dialog" and the user needs to agree for the driver to be installed.

Thanks for the great tools, keep up the great work guys!

9/23/2005 8:41:00 PM by Anonymous
# re: Multi-platform Images

If anyone wants to create installers using the free, open source WiX toolset, see my post of 3 months ago on the Forums...

http://www.sysinternals.com/forum/forum_posts.asp?TID=188&KW=n00dles

9/24/2005 7:07:00 AM by n00dles
# re: Multi-platform Images

Please keep your wonderful tools in ZIP files no matter what you decide about MSI. Hundreds of our customers have policies preventing from running any kind of installers for "unplanned" products on their servers. Moreover, some of them have equipment in areas where the difference between 0.5 MB and 2 MB to download is still very noticeable.
Thanks!

9/24/2005 12:51:00 PM by Anonymous
# re: Multi-platform Images

Kudos for the tools and these are simply the best :-) With such a small size, I dont mind to download it as many times directly from your site. It will not take much time and certainly MSI is always not the best.

Thanks again,
Athif
WESUS Blog: http://msmvps.com/Athif

9/25/2005 8:34:00 AM by Athif
# re: Multi-platform Images

Kudos for the tools and these are simply the best :-) With such a small size, I dont mind to download it as many times directly from your site. It will not take much time and certainly MSI is always not the best.

Thanks again,
Athif
WSUS Blog: http://msmvps.com/Athif

9/25/2005 8:35:00 AM by Athif
# re: Multi-platform Images

yall are nuts with this installer stuff

i keep them on a usb key and a folder/share included in my set path variable

9/25/2005 6:38:00 PM by Anonymous
# re: Multi-platform Images

Context plays an important part as well.

Almost every time I need these tools, It's on some test or prod system somewhere that I need to take a look at. It's way, way easier to just grab the file and unzip it, run it off the desktop, and then delete it, then it would be with an MSI.

Because these tools get installed/removed so often, it makes complete sense to minimize the overhead of install.

9/26/2005 1:33:00 PM by Rob Meyer
# re: Multi-platform Images

I usually unzipped all of the tools need to the same directory, say "C:\SysInternals", and put the path into environment variable PATH. But I found it difficult to find and update the tools to their latest version.

9/26/2005 7:55:00 PM by zedware
# re: Multi-platform Images

the only advantage of an 'installer' would be to allow non-admins to be able to run the various sysint tools.

To install the drivers and run these tools (I assume (am I wrong??)) you need to be an admin. What if I want to give a non-admin user rights to a sysint tool?

It might in this case be helpful to have a "driver pre-install" option that gets the 'admin operations' out of the way & would subsequently let non-admin users use the tools.

Problem is that Mark usually loads the driver and then deletes it from disk. For a 'non-admin preinstall' he'd have to likely keep the file around on disk for future loads.

Or, I'm sure, we could all buy Winternals Protection Manager to elevate privileges on the fly, right Mark?

9/27/2005 12:56:00 PM by Anonymous
# re: Multi-platform Images

totally agree, installers suck.

ps: the 4th ed book is great, good job on it, lots of new info and goodies

9/27/2005 12:58:00 PM by Anonymous
# re: Multi-platform Images

All these folk complaining about not having a .MSI, and worse, b*tching and moaning about the lack of "shortcuts" (WTF are they?? 8-) ), are clearly too stupid to know about things like PATH environment variables and intelligent system configuration. It surprises me that such a level of retardation is commensurate with understanding the point and function of most SysInternals tools...

The only change I'd suggest (to make finding updates easier) would be to include the version number in the .ZIP file's name on the server.

9/27/2005 7:37:00 PM by Anonymous
# re: Multi-platform Images

As much as I love the tools, and like the fact that they don't require "installation", I often find myself wanting to use the tools on systems that don't have an unzip tool. It would be very convenient to just publish an unzipping EXE or the individual programs as EXEs (not self-extracting; just the program without the README).

9/28/2005 6:44:00 PM by Gabe
# re: Multi-platform Images

You seemed to imply in the article that everything was packed inside the 32 bit executable in a flat manner, however (at least in the case of Process Explorer) I've been running the extracted version of the 64 bit binary for a while without an issue (I copied it out while it was running).

Is this working just because I haven't rebooted my machine in a while and the driver is still loaded, or is the driver actually embedded in the 64 bit version, which in turn is embedded in the 32 bit version? Running "strings" on the 64 bit version seems to imply this is the case - just curious.

9/28/2005 7:13:00 PM by JohnW
# re: Multi-platform Images

I think you could drop the zip and use some exe compression which does the uncompress phases to memory directly. This would remove the need for unzip and possibly make the loading faster if you could avoid touching disk after the initial exe decompression to memory.

Also if the machine is on the Net, all the tools could inform about newer version and offer to update the exe on disk, but not inform about it with a popup, but some inobtrusive way, perhaps in the application tittle bar.

10/3/2005 1:24:00 AM by Anonymous
# re: Multi-platform Images

Hey Mark,

Your tools are fucking great. Even my dog use them!

10/3/2005 4:37:00 AM by Anonymous
# re: Multi-platform Images

Sorry, just kidding. I was too excited :P

10/3/2005 4:39:00 AM by Anonymous
# re: Multi-platform Images

Thanks for the feedback!

10/3/2005 10:20:00 AM by Mark Russinovich
# re: Multi-platform Images

Mark,

I would love to hear your reply to (ANY!) these posted comments. Especially the developer oriented comments.

A great articles, yes, but it seems that all these folks are all speaking into the wind. Why do they bother then? Posting a comment in search of a reply seems resonable. Yes?

10/4/2005 11:48:00 AM by K.C.
# re: Multi-platform Images

I'm not sure what kind of reply you're looking for. My views are unchanged from those I presented in the posting and I think supported by the vast majority of sysinternals tools users: I plan on continuing a policy of setup-less applications.

10/4/2005 2:59:00 PM by Mark Russinovich
# re: Multi-platform Images

I love the 'cleanliness' in this solution. Its awesome.

Reading some of the other comments where people wanted to automate installation, I guess they are looking at avoiding to use zip file, one way to do that would probably be a self extracting exe? ;-).

However, keeping your EULA in view, you probably don't want people to be automating and distributing your tools across their company without licensing properly.

Please keep up the good work.

10/12/2005 11:11:00 PM by Anonymous
# re: Multi-platform Images

The current registry based options arrangement would seem to contradict the theory of setup less install...

It would be great if options could be XML or INI based, the tool could look for a config file of the same name...

Love the tools, even without installers...

Thanks for making these available,
Dennis

10/14/2005 6:54:00 PM by Dennis Bareis
# re: Multi-platform Images

Um, the 64-bit scheme suggests a problem to me. What if the user running the program does not have write permission to the folder containing the 32-bit exe? (Which describes how I use your tools on my network mostly -- except that I have no 64-bit kit yet)

Will the 32-bit stub write the 64-bit image into %USERPROFILE%\Local Settings\Temp, perhaps? Or maybe just into %TEMP%?

10/15/2005 1:55:00 AM by Ross
# re: Multi-platform Images

Mark,
What has changed in 2003 that forced you to write a seperate driver for 2003 server? I thought that it is simillar to XP. Can you shed some light on how this stuff works? Thanks.

11/4/2005 5:07:00 PM by TomVeeYes
# re: Multi-platform Images

I got curious after reading your question and I took a look at the drivers that came with regmon.exe; the main difference that I've found is that the old NT driver imports KeServiceDescriptorTable to hook a couple of functions and the 2K3 driver doesn't import it but it imports two functions to 'hook' and 'unhook' the registry provided by Microsoft: CmRegisterCallback and CmUnRegisterCallback.

After this discovering I went to the MSDN and found that these functions are available from XP so I got confused again.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/Kernel_r/hh/Kernel_r/k102_ec214e13-1342-48b5-9a31-8c6c9da57cd6.xml.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/Kernel_r/hh/Kernel_r/k102_13cbc14e-4652-4a3d-a87e-f6eef883f912.xml.asp

I'm not sure but maybe this fact is the one that hit the target:

"For Windows XP, the system only makes post-notification calls only when a registry key is created or opened. For Microsoft Windows Server 2003 and later operating systems, the system makes post-notification calls for every registry operation"

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/Kernel_r/hh/Kernel_r/DrvrRtns_988f8f3d-4ee8-4351-8fc0-703a88bd8421.xml.asp

Anyway, all that I have said is pure speculation :=)

11/5/2005 7:28:00 PM by Eternal Idol
# re: Multi-platform Images

DUDE!! YOU ROCK!! HEHEHEHE. KICK ASS!!

Well done!! Thanks for your efforts and time spent! Your knowledge is worty of envy :P

Rock on! My comment is probably gonna be lost in the crowd, but one day when you see this, know that you made a difference.

11/9/2005 9:32:00 PM by dvius
# re: Multi-platform Images

From http://news.bbc.co.uk/1/hi/technology/4424254.stm:

"Mr Russinovich has continued his investigation of the XCP software and has confirmed that when installed it can make a Windows computer more unreliable."

Gotta love that "more"...

11/10/2005 7:22:00 AM by Phil
# re: Multi-platform Images

Hello, just to advice that a trojan is already using the Sony DRM rootkit:

See it here

11/10/2005 9:25:00 AM by xtracto
# re: Multi-platform Images

More info on the trojan here

11/10/2005 10:41:00 AM by calzakk
# re: Multi-platform Images

This whole episode should be considered as much Microsoft's fault as Sony's. It's absolutely ridiculous to setup a system where you have to be running with administrator (i.e. full system) privileges in order to install application level software.

I was an IBM mainframe software developer for many years (I worked in assembler), and I can tell you that no software, other than system level utilities, was allowed to run on the mainframe with full system privileges (it was called APF authorized in IBM speak). You could install all application software without those privileges.

Microsoft really screwed up when they bundled everything into the registry, whose hives all except CURRENT_USER require administrator privileges to update. This forces all software installs to be done from and administrator level account, and effectively gives complete control of the machine to any installation program. The user has no idea what might be modified by the installation program, including the kernel and interrupt routines. This is the root (pardon the pun) of the vast majority of problems with malware that we have today.

I sure as hell hope that the next version of Windows changes the rules so that you can install software without having administrator privileges. They also need far more granularity on how system privileges are granted. The core OS files and in-memory structures should be completely protected from manipulation by outside programs unless an administrator level user has given explicit permission to allow this activity (e.g. when you install anti-virus or firewall software).

11/10/2005 2:54:00 PM by gmudtoe
# re: Multi-platform Images

I guess that your worked in assembly language, that's great but it doesn't have anything to do with multiplatform images, right?

Come on all of you this is not an entry about the Sony rootkit!

11/11/2005 4:23:00 AM by Eternal Idol
# re: Multi-platform Images

Hi Mark
It's been a longe time since last Amsterdam.

The sony story seams to get a nasty tail. there is a news article on CNN some hackers now use similair hiding filenames in combination with sony's protection.

I think now sony has made it easy for hackers to hide their viral software.

11/11/2005 8:54:00 AM by PGT
# re: Multi-platform Images

Again:

Come on all of you this is not an entry about the Sony rootkit!!!

11/11/2005 11:48:00 AM by Eternal Idol
# re: Multi-platform Images

With regard to someone's comment that the responses aren't on topic to "Multi-platform Images", the reason the comments are here is that the blog entry regarding the Sony rootkit has a link to this thread as a place to post comments.

One other thought regarding this rootkit business. I'd be concerned at this point about buying a Sony laptop computer, DVRs, cameras, or even a DVD player. Who is to say what software, or “special BIOS code” they may have pre-installed on the machine that they aren't telling you about. I get the feeling that Sony's business model is moving from selling equipment as a primary business, to one of licensing of content (music, movies, games, etc.); and that the selling of equipment (laptops, DVD players, TVs) is morphing into more of a means of getting people to license content rather than an end in and of itself. If that's true, then this event makes it look like Sony lacks the scruples to avoid surreptitiously placing whatever DRM or phone home code they think is in their own best interests into any hardware you buy from them, including laptops. If they are willing to put a rootkit on your system from a music CD, what is stopping them from putting one on when you attach a digital camera via the USB port? There are all kinds of ways to introduce rogue code into your system when you plug in a USB device. I was toying with the idea of buying a Sony laptop (the new small one with the wide screen), but not anymore. From now on I’ll be very careful about buying anything from Sony that has the potential to talk to the rest of my home network or the internet, or interact with any of my PCs, including digital cameras.

11/11/2005 4:51:00 PM by gmudtoe
# re: Multi-platform Images

http://news.ninemsn.com.au/article.aspx?id=71751

Sony has ceased production of copy protected cds!!

11/11/2005 6:21:00 PM by Jessica
# re: Multi-platform Images

Got Sony's Email to remove the rootkit, ran it, and guess what - it's not removed.
This process is still running:
O16 - DPF: {4EA7C4C5-C5C0-4F5C-A008-8293505F71CC} (CodeSupport Control) - http://www.xcp-aurora.com/clients/SoftwareUpdate.cab
Media Jam folder is still there and Unicows.dll is still present. What next?

11/13/2005 6:57:00 AM by Steve
# re: Multi-platform Images

I recently stumbled on the whole SonyBMG malware issue! The whole thing makes me unbelievably angry! It is quite enough to have hackers invade your home thru whatever creeping means they can come up with it. It is completely different to hold the door open and unwittingly invite them in. It is a breech of trust, most particularly when the invasion comes in the form of a well known and trusted entity. SonyBMG has jumped off the pedestal created by the music industry. They've negated any sympathy factor that may have been their due because of the issues of CD piracy. They gave up their entitlement to righteous indignation when they stooped to imbedding malware in their CD's. What makes their actions most heinous is the fact that we purchase the malware from them and pop it right into the computer! They aren't coming in under the cover of a malicious or tricky email, they trick the consumer into PAYING them good money for their malware!
As I sat and read Mark's post's I envisioned Superman engaged in battle with the evil Lex Luthor. I am greatful you're there doing battle for the little people. (read: computer illerati) It is quite thrilling to watch as you expose their lies and demand an explanation.
My first action was to end my membership to BMG music club. (Formerly Columbiahouse) A truly small thing considering how little I actually purchase, but it did fill me with all kinds of warm fuzzy's for having taken some action. The one final word that comes to mind? BOYCOTT.

11/13/2005 5:01:00 PM by Glory
# re: Multi-platform Images

I find it irritating that people would whine about a break from Windows 95.

2/5/2006 5:43:00 PM by Soby
# re: Multi-platform Images

Yes, I remeber seeing this in those executables you download from sysinternals. I remember some tester had needed to do a COM port monitor a few years back so I suggested to stop the deleteion of this driver and copy it. I then just debugged the interface between the application and the driver. They were then able to use the driver to cut down on their work load and provide a test case for COM port verification.

4/23/2006 12:36:00 AM by Anonymous
# re: Multi-platform Images

I don't know the technical issues, but isn't it exactly the same problem that the Apple guys solved in the days of NeXT with "Fat Binaries". Today Apple call them the "Universal Binaries" which comprises a single application package with multiple binaries for many different architectures where the operating system is able to choose which one to execute. It is very clever and transparent for the user.

7/10/2006 4:21:00 PM by Anonymous
# re: Multi-platform Images

I'd like to suggest a further enhancement to your extract logic for drivers. When running under BartPE, the place your exe is located, the CD, is also read-only. You've seen workarounds for this already, and the latest versions don't requre patching with a hex editor. But, why not extract to the TMP location, or other directory specified in an environment variable? I have a harmless writable location on B: running under BartPE, for example, even when I'm wanting to not write anything to the hard disk.

9/14/2006 2:35:00 PM by John Dlugosz
# re: Multi-platform Images


"It is also quicker to install an MSI than a zip (and installation is easier to automate)."


I get the feeling some of you are using bloated and needless programs like Winzip to unzip your files.

Use Total Commander or a two panel file manager. As soon as a zip file finishes downloading in my web browser, I open the file in total commander and all the files are immediately visible, with another folder ready to copy in the other panel.

A zip file is much faster an easier to install than an MSI if you are an advanced user who uses proper tools.

However, many people still don't have proper file management tools and stick to using horrible tools such as Winzip and Windows Explorer. This is the reason you folks find MSI's easier to use - because you don't have the proper tools to deal with Zip files.

If you are afraid of paying for a total commander license and you prefer Windows Explorer and WinZip because they are available for free - well, total commander can be used for free too - you just have to click a button each time it starts up, sort of like how winzip makes you click a button. I'm also working on a free Light Commander program which will be freeware.

I really recommend you try using better file management tools - I used to hate zip files when I used winzip. The problem was winzip, not zip format! Winzip is a clunky "for beginners" interface that makes unzipping files easy for beginners, but complicated for advanced users.

Total commander treats all zip files, gzip files, 7zip files the same way. It is treated as if the files were right on your hard disk. You can browse zip files just like you can a directory on your hard drive. And this was possible ever since Windows 95 - this isn't just available today. Most people have just not experienced the speed and ease of use that Total Commander offers.

I don't even work for Total Commander nor am I getting paid to send this message - in fact I have software that competes with Total Commander so you can be rest assured that I'm truly recommending Total Commander. Throw your winzip program in the garbage. (don't make me start commenting on your poor FTP programs which Total Commander can replace also).

10/17/2006 2:01:00 PM by L505