Booting an arbitrary image inside boot.wim

[JFX]

Yeah, you really did, works great.

Had take me some time to notice that I was using your trimmed down boot.sdi all the time

Thanks a lot for making this possible.


BTW: interesting that every time, the boot index is changed via imagex, the image is growing ~270 KB.

[joakim]

Oh yes it will not work with my custom trimmed down boot.sdi as that size is way below 306000h. Actually what happens is the first instruction in my added code at 462200 is a cmp against the esi register where the size of the target file is given. If it does not equal 306000 (it must be the wim image) then jump to patching routine, else continues execution and returns back to origin.

I know this is not fool proof, because 2 things can happen which will prevent further booting;
1. The size of the boot.sdi is not 306000h (like my custom one). But if you stick to the original you are safe.
2. The size of the target image is equal to 306000h. But that is just not possible as an nt6 based WinPE cannot be that small!

But if someone wants to use my custom boot.sdi with this approach then just modify the instruction at 462200 accordingly to reflect the size of that one.

He he sometimes all those small details really contributes to confuses. For instance it took me 1 hour to figure out why my code in menu.lst or map to (rd) was not working the first time (it just froze). Answer: I had configured boot debugging and forgot about it.

Joakim

[joakim]

About the wim header, it appears that the only values that change are for the rhBootMetaData and dwBootIndex

Code: Select all

WIM Header
typedef struct _WIMHEADER_V1_PACKED
{
   CHAR              ImageTag[8];        // "MSWIM\0\0"
   DWORD             cbSize;
   DWORD             dwVersion;
   DWORD             dwFlags;
   DWORD             dwCompressionSize;
   GUID              gWIMGuid;
   USHORT            usPartNumber;
   USHORT            usTotalParts;
   DWORD             dwImageCount;
   RESHDR_DISK_SHORT rhOffsetTable;
   RESHDR_DISK_SHORT rhXmlData;
   RESHDR_DISK_SHORT rhBootMetadata;
   DWORD             dwBootIndex;
   RESHDR_DISK_SHORT rhIntegrity;
   BYTE              bUnused[60];
}
WIMHEADER_V1_PACKED, *LPWIMHEADER_V1_PACKED;


Note that rhBootMetadata occupy the 24 bytes prior to dwBootIndex, and is presumably constructed like this; SIZE, OFFSET, UNKNOWN_TO_ME.

Here are my 4 different wim headers;






Joakim

[JFX]

Made small tool to get "menu.lst" style info from WIM file.

CheckWIM.7z

[joakim]

Very nice JFX. Thanks!

Just tested it, and it works perfect. May I request an additional feature to add the image name behind the image index number (sometimes you just don't remember which image was what..). One way is to dump the xml info to a file and retrieve what is between <NAME>...</NAME>.

I'll rewrite the first post to include all links and relevant updated information.

Joakim

[JFX]

Good idea. Have updated tool, the title now contains the Name of the index.

[joakim]

Great work!

First post now contains all relevant information including link to your tool.

[joakim]

For those that are using my special boot.sdi at 300 Kb, http://www.msfn.org/board/topic/145209- ... f-bootsdi/ ,it is necessary to patch 5 instructions. Add this to your entries in menu.lst;

Code: Select all

write --offset=0x653D3 (rd)+1 \xB0\x04
write --offset=0x653F4 (rd)+1 \x00\x57
write --offset=0x65402 (rd)+1 \x00\x57
write --offset=0x65410 (rd)+1 \x00\x57
write --offset=0x6541E (rd)+1 \x00\x57


Joakim

[joakim]

If you want an entry in menu.lst for booting a wim without patching the header (ie boot the default as given in header), then add an entry like this;

Code: Select all

title Boot a normal boot.wim without header patching
map --mem /wimpatched (rd)
write --offset=0x19FE6 (rd)+1 \x89\x45\x10\x85\xC0
chainloader (rd)+1
root ()


Now we are basically patching the code back to what it was originally, without making a call to my custom code. The call is thus overwritten by the original mov and test instructions.

Joakim

[JFX]

Okay let me try with the 692 KB boot.sdi.

Code: Select all

write --offset=0x653D3 (rd)+1 \xD0\x0A
write --offset=0x653F4 (rd)+1 \x20\x5D
write --offset=0x65402 (rd)+1 \x20\x5D
write --offset=0x65410 (rd)+1 \x20\x5D
write --offset=0x6541E (rd)+1 \x20\x5D

The first write is the size of the boot.sdi and the following 4 are the original values of your patch,
reduce by the difference in size from the new to the original boot.sdi?


BTW: Have updated CheckWim tool, now also delete temporary wim file.

Also added /decompile switch if you interested or like to modify it.

[joakim]

Explanation:

Wim is found right after boot.sdi in EAX. The base in eax is 525000, ie eax+525000, and is the beginning of boot.sdi. So if boot.sdi is 3170304 bytes (the original), we must convert to hex and add it to 525000. My 696 Kb version of boot.sdi is 712704 bytes which equals AE000 in hex.

Code: Select all

with original boot.sdi
525000+306000=82B000
location of wim header = eax+82B000

with minimal boot.sdi
525000+4B000=570000
location of wim header = eax+570000

with 696 Kb boot.sdi
52500+AE000=5D3000
location of wim header = eax+5D3000


That means we must first adjust the size of boot.sdi at VA 462200. The size of target file is given in esi;

Code: Select all

original boot.sdi
81FE00603000  cmp esi,00306000

minimal boot.sdi
81FE00B00400  cmp esi,0004B000

696 Kb boot.sdi
81FE00E00A00  cmp esi,000AE000


And then we must also adjust the new memory location of the wim header (start of your wim file). The original location of wim header offset 0x60 is eax+0082B060. The new instruction then become;

Code: Select all

original boot.sdi:
899060B08200  mov eax+0082B060,edx

minimal boot.sdi:
899060005700  mov eax+00570060,edx

696 Kb boot.sdi:
899060305D00  mov eax+005D3060,edx


And the same goes for the instructions at VA 46222F, 46223D and 46224B.

So for the 696 Kb boot.sdi you will need to have these values in your menu.lst;

Code: Select all

write --offset=0x653D3 (rd)+1 \xE0\x0A
write --offset=0x653F4 (rd)+1 \x30\x5D
write --offset=0x65402 (rd)+1 \x30\x5D
write --offset=0x65410 (rd)+1 \x30\x5D
write --offset=0x6541E (rd)+1 \x30\x5D


Remember we don't have to change all values, only those that have changed.

Btw, why are you using the 696 Kb version of boot.sdi?

Joakim

[JFX]

Thanks for explanation. this clears things up

Well I use the 692 KB version just because it was the last one with valid file system, and using this one now for good 2 month without any problem.

[kpdozer]

There is one insignificant lack
Boot.wim boots in the RAM completely, including all images inside. It is necessary that boot.wim (with several images) was located in the RAM. To calculate the correct size difficult.

[joakim]

I know this is a drawback, but it is very difficult task to solve. I believe it should be possible, but I am not sure how at the moment.

The biggest advantage from this is when you have different images based on the same Windows version (the files are mostly the same). Then not much memory is wasted and the size of the wim will not increase by much. If you have 2 images based on 2 different Win versions, then boot.wim will be much larger and memory is handled inefficiently with my patch. But with 2 similar OS's then memory handling is fine.

The major advantage is definetely required storage space.

Boot time will of course increase with the size of boot.wim.

I am not saying this is a brilliant and ground-breaking solution. I just took a challenge and solved it.

If you or anybody else known a possible way to solve the issue of the complete wim loaded, then let me know.

Joakim