joakim

None of those documents/tools can get this information. Imagex.exe/wimgapi.dll will show you some basic information about the wim, except for those 3 fields as specified in the first post. The wim format document will tell you what is what for the individual parts, but has omitted to explain anything about those 3 header fields. That said, imagex.exe is surely capable of retrieving this piece of information from somewhere. But from where? I suspect we need to create something on our own to get this information, or completely disassemble wimgapi.dll... I will keep on digging, but could need some help.. Btw, these 3 fields are the only parts in the header that needs to be patched, to boot another image. Joakim

I am working on a patch for bootmgr that may boot any image inside of boot.wim. For the wim format specialists of this forum; How can we retrieve these fields, as specified in the wim header, from any image contained in boot.wim; rhOffsetTable rhXmlData rhBootMetadata It is basically size and offset for each of the 3 resources. I had a quick look at the documentation for wimgapi.dll, but have my doubts that wimgapi.dll is capable of retrieving this information. These values are going to be patched into the wim header as read into memory by bootmgr.. Joakim

User hgiova contacted me about a month ago and asked about the possibility to integrate several images inside boot.wim, and choose which one to boot. I just recently started on this, and believe it should be possible to boot a "non-bootable image" inside a wim. By "non-bootable image" I mean an image contained in the wim that is not specified as the boot image in the wim header. Details here on the state of the research; http://forum.sanbarrow.com/viewtopic.php?f=85&t=15 The point is that it could be rather interesting to have this task solved, and be able to integrate many nt6 based PE's in the same wim (of course not for PXE). Several hundred megabytes could be saved in space. I am rather sure that we must use grub4dos and map bootmgr to the (rd) device and patch it there. I am getting closer to finding the correct VA to patch (and what to patch it with), but if any assembler knowledgable people would join in, it could possibly speed up the process quite a bit. Basically (I think) it's just a matter of patching the resource offset as specified in the wim header (found in a given register, ie esp+68h). I doubt 0x78 is read at all, but patching that too probably doesn't hurt. If someone knows about an easy way of retrieving the resource offset for a given image, let me know. Note that it is obviously not possible to use the compressed bootmgr.exe when patching this way. Use uncompressed bootmgr.exe, otherwise known as the pxe version. Hmm, and you will need to do some additional hacks to acomplish this. I'll post that later if necessary. Nevermind, I just saw that I already gave a link for that in the first post. Joakim

By default the key is not there, and the size then defaults to 32 mb. To specify something larger you must create/modify the key "WinPECacheThreshold". Value must be in hex, ie 64 mb = 40. Joakim

The point is me and him is discussing the details in that thread, but he missed a few important details. That's why it currently does not completely work (the animation part aparently now works). As soon as he's sorted everything out, it will work. And it will be a really great app when finished. If you do it manually like I've done, you should get it running. Just follow the tutuorial, including some extra information in the following posts. The real challenge is how to achieve it without testsigning on.. Joakim

It is possible for both 32-bit and 64-bit. I know because I have done it myself on both architectures. Read about the details behind that tool, where it's all discussed, in this thread; http://www.sevenforums.com/customization/106861-how-change-boot-animation-windows-7-a.html Joakim

Yes I am aware of the pxe fact, but such slow links are getting rather unusual nowadays I think. If this boot.sdi will help then very good to hear. But keep in mind it has not been extensively tested. I cannot guarantee that it works in any environment. If you run into problems with it, let me know. Joakim

We have also discussed how to the change the boot animation, etc; http://www.sevenforums.com/customization/106861-how-change-boot-animation-windows-7-a.html In case you keep rebooting a lot and got bored of the default animation, image and text.. Joakim

You don't have to "hack" anything to accomplish that. It is an option available when setting "optionsedit on" on a specific bcd entry. If you do so you will get the tweakable options listed on a command line, where you can edit them to your likes, and have to press enter when done. That means the boot process will halt at the edit screen, so you only want to do this in very specific cases. However it may help you to "translate" bcd entries into boot.ini equivalents, as they are presented on the edit screen in such a way as they were in boot.ini. The optionsedit setting is also documented by MS in the bcd reference. Only in ntldr you would need to "hack" to activate the optionsedit function. Details already in the referenced thread. Joakim

You can read more about customization of bootmgr here; http://sanbarrow.com/phpBB2/viewtopic.php?p=7472#7472 Stuff like changing the menu colour, toggle maximum menu entries and how to local boot the pxe version of bootmgr (bootmgr.exe).. Joakim

No, not except preventing an insignificant waste of resources. That's why I said only consider it as a PoC. Joakim

That is expected behaviour since the ntfs filesystem is invalidated. No existing tool will be able to mount that partition image normally. You must use a hex editor and/or a similar low level reader (like ntfs diskexplorer). Btw, the starting offset is 4096 and not 8192 (determined by the page size of the sdi). The bootsector is completely removed. The first version that you mention is mountable, has a good and valid filesystem, and therefore is possible to mount using "normal" tools. Joakim

Are you sure reg.exe cannot handle offline registry hives?

Microsoft still uses the same file they created for Longhorn on 15.02.2005, over 5 years ago (assuming their timestamps are more trustworthy than mine). Three severely retarded things are worth noting about the original boot.sdi; 1. The $LogFile is 2 Mb 2. Free space is set to 0,6 Mb 3. Page alignment is set to 8192 bytes (instead of 4096) in the sdi header Strange that they still keep this one. Joakim

Size now at 307 200 bytes; http://www.mediafire.com/file/k3qdkrucb6ce8ej/boot_sdi_300.zip The partition image is now basically constructed like this; Sector 0: $Boot Sector 1 - 64: $MFT Sector 65: $MFT:$Bitmap Sector 66 - 73: Root directory Sector 74 - 586: $LogFile The rest of the systemfiles are found "inside" the $LogFile starting at sector 136. It is now much easier to read it too. Also tried putting the $LogFile in sector 1 and placing all other systemfiles inside it, but that did not work. Btw, it is a really good way to learn about ntfs when working with such a small partition image. Joakim

That's right. It will bsod 0x..ED with a fat partition. Joakim

According to their own doc, it must be ntfs for rw's; http://technet.microsoft.com/en-us/library/cc722145(WS.10).aspx Joakim

Size of boot.sdi is now 319 488 bytes: http://www.mediafire.com/file/cvabeux4rj6xri6/boot_sdi_312.zip The interesting stuff is that some metafiles only need to have some of the first bytes present. And some of them are not read at all. But since their reference can't be removed from $MFT, their occupied sectors can be filled with 0's. Namely $MFTMirr and $Bitmap are not read at all. $MFT and $AttrDef are not modded at all. For $UpCase only the first sector needs to be present. As mentioned before, the $Boot can be reduced to 1 sector (IBL not needed). The $LogFile only requires the first 8 sectors to be present (rest can be 0's). However the size of the LogFile can't be reduced from its current size of 262 656 bytes. Now the most interesting bit is that some metafiles can be cross referenced, meaning they can occupy the same sectors. This will be true when certain sectors are not read, or their content are the same (like with the 0's). In this boot.sdi, as much as 3 metafiles are located on some common sectors. The $Secure metafile effectively only takes 1 sector (rest can be 0's). It is entirely located inside $LogFile, and because $LogFile can't be shrinked, I did not bother much about its size. If the $LogFile can be reduced in size, it is likely that the total partition image size can be reduced to the crazy size of 73 216 bytes!! This must only be considered as research and a PoC. It works, but has not been extensively tested. Joakim

I am a little bit confused.. What kind of packages are you working with and to what kind of host are they installed/uninstalled? Joakim

So I assume you are capturing the changes when installing packages in the Windows 7 Embedded environment. I tried that some time ago, but always got errors. Thought about raising the question in the embedded forums, but forgot about it.. So can you install & uninstall packages on an embedded 7 "machine" with dism? What tool are you capturing with? Joakim

Last shot at 692 kB; http://www.mediafire.com/file/xq03xipghtjns31/boot_sdi_692.zip By shrinking the metafile $Boot from 8 192 bytes to 512 bytes, the total partition size is now 684 kB or 700 928 bytes. The partition has no free space and only contains ntfs systemfiles. It will only work for booting nt6.x based winpe (does not write anything to the partition, just mounting the wim). I doubt it is possible to reduce the size of it any further. Partition image is also included in download. Joakim

Here is a new one at 696 kB; http://www.mediafire.com/file/5p9nsoep8o7f5ib/boot_sdi_696.zip It is a modified version of Mark's ntfs partition. The partition image is only 708 608 bytes. I wonder why Microsoft made their boot.sdi almost 4,5 times the size of what is necessary? It is really just a waste of space.. Joakim

Cool, I did not know. Will investigate it soon and see what we get.

I've been annoyed by the +3Mb size of the supplied boot.sdi that is shipped with nt6.x. It is really a size overkill! My tweaked boot.sdi is now at 960 kb, or 983 040 bytes to be exact. The boot.sdi is basically an sdi with just a tiny ntfs partition image injected and a marker for the "mysterious" wim blob at the very end. Download at; http://www.mediafire.com/file/t0zzwmwwylb/boot_sdi.zip If anyone can reduce the size further, I would be happy to inspect the file. Why on earth did MS make it so big? Only answer can be that they are lazy and don't care about a few MB of wasted space Joakim Updated version 300 kB; http://mft2csv.googlecode.com/files/boot_sdi_300.zip Details of sectors inside the latest partition image; $Boot 0 $MFT 1-65 Root directory 66-73 $LogFile 74-586 $MFTMirr 136-143 $UpCase 136 $Secure:$SDS 137-392 $Bitmap 138 $AttrDef 139-143 The rest of the systemfiles are fully contained within $MFT The reorganization of the ntfs metafiles was done to make it easier for those that want to decode and understand it.

I have had several pcmcia cards with atheros chipset, and these could support monitor mode on Windows if used with the old win version of airodump (don't know the current state on this though). Then decrypt it with airdecap-ng. A commercial Windows alternative is OmniPeek (very broad chipset support), but costs enough to scare you off. As CoffeeFiend says, linux is by far the easiest and best platform to do this invisibly. WebWatcher can, by definition, not be invisible as they claim, as it must be installed on the target (although it seems like a nice comprehensive aio solution).