What I describe here is how to manually change the boot animation, the four lighting balls that turn into the Windows flag. I will also explain in detail how to modify nearly everything until after animation is finished playing.
Before we start I can say that it is also possible to switch to a static boot image by patching the kernel. Just do the same thing you did on nt 5.x. Replace the first bitmap in the kernels resources.
To change the animation there are several things to remember. Unless you want to patch bootmgr and winload.exe, you must configure TESTSIGNING on in the BCD. It is possible to do this without TESTSIGNING, but we will get to the details later on. And the hacks work equally fine on x86 as on x64!
Unless you want to read about the details, you can go straight to user thaimins's (Jeff) excellent application that will do it all for you and supporting both 32 and 64-bit;
http://www.coderforlife.com/projects/win7boot/ and here's also a link to a good collection of animations on a german forum;
http://www.deskmodder.de/phpBB3/view...?f=220&t=13363 1. Now the animated bitmap, activity.bmp, is loacted inside a wim in bootres.dll. We will first need to extract the wim, so we open the dll in resource hacker and export the resource named RCData. The wim can then be mounted with lots of tools, like 7zip and gimagex. Inside there is activity.bmp found. I will not make this a tutorial about animation, so for the sake easyness we just open the file in paint.exe and see that there are a numerous bmp's stacked over each other;

I know nothing about animations so I just modify the bitmaps like a retard would do.
2. When the animation work is done, we must pack the bmp into a wim again. Preferrably use gimagex and fill out information anf boxes like in this image;

Notice the name, the compression (max) and the boot flag. You better create a new wim instead of reusing the old one. That way the size is much smaller.
3. Now we must replace the resource named RCData inside bootres.dll with the wim we just created. Use resource hacker like this;

4. Now we need to clean the pe header for the (old) pointer to the previous Certificate Table that we now have removed/invalidated. Fire up bootres.dll in a hex editor and fill 8 bytes of 00's at offset 0x150 (representing the offset and size respectively for the Certificate Table. Actually this can vary so better check 0x3c for the location PE header and then move another 0x98 from the PE header location, and you will land on the right place. Like this;

Or you may grab a PE-editor to do the work for you.
5. Update the checksum of bootres.dll as found in the PE header. (I have made a custom one myself but cannot find it..). Therefore use the PE-editor or any similar tool to correct the checksum.
6. Now we can sign the file with a test certificate. It is important to erase any previous pointers to the table, as descibed in point 4, otherwise you likely will not be able to sign the file.
After successful signing, the properties will hopefully look like this;

Do not bother with the timestamping. It will not make any difference really.
7. This step is only necessary if you are going the testsigning route. Add it with a command like this (adjust the path and guid);
Code:
bcdedit /store v:\boot\bcd /set GUID testsigning on
8. Works on both 32-bit and 64-bit! Good luck.
This is how one of my tests went;
And for historical purposes I will keep as evidence my first (and by far the lamest ever) modded animation;
Some more technical details:
Removing watermark when TESTSIGNING is configured.
Regarding the "Test Mode" watermark in lower right corner, it can be removed by zero out string id no 738 in user32.dll.mui, update checksum, and rebuild mui cache.
http://deepxw.blogspot.com/2008/12/r...-20081210.html
BOOTMGR
Is composed of a 16-bit stub and a 32-bit executable (bootmgr.exe). Inside the 32-bit executable the ere is an xsl resource with lots of stuff that can be tweaked. After Vista the 32-bit part was compressed, which means you must decompress it before you can analyze the pe file. This way more code can fit into 512 Kb. Thaimin made this great tool, bmzip that will compress/recompress bootmgr;
http://www.coderforlife.com/projects.../extras/#bmzip. It is also possible to boot with uncompressed bootmgr.exe (pre Vista). For that to happen you must grab bootmgr.exe and delete some of the unneeded stuff in the xsl resource (like network/multicast and certain error messages), as well as the embedded digital certificate. Then attach the 16-bit stub from Vista SP0 that could handle uncompressed bootmgr.exe.
Without TESTSIGNING
This is divided in 2 parts. There are many ways to achieve this, but I mention only what is strictly necessary.
The first is about bootmgr only. At VA 421EC5 change 7416 to 9090. That will deactivate the signature validation inside bootmgr. If you don't do this then you must set TESTSIGNING on for {bootmgr}. Optionally you can deactivate the checksum as well. If so then change EB08 to 7403 at 0x105E in the stub. If not then NOINTEGRITYCHECKS must set on for {bootmgr}. But if checksum is corrcted in bootmgr.exe after modification then this last step is not required.
The second is about winload.exe and handles all other files after bootmgr during the boot. It is basically the same hack as for bootmgr. At VA 429612 change 7416 to 9090. Now winload.exe and all files loaded later, doesn't have to be signed by a test certificate. Just make sure you just have some dummy values for the Certificate Table in the Data Directories.
If you want to completely deactivate all checksums, so that you can boot with bad checksum in all files after bootmgr, we must patch winload.exe in 3 places;
Code:
at VA 428DC5 change 7418 to EB18
at VA 428DE3 change 0F8400010000 to 909090909090
at VA 428DF6 change 0F871CFDFFFF to 909090909090
Translate from va to raw offset;
Code:
va 429612 = raw offset 28a12
va 428dc5 = raw offset 281c5
va 428de3 = raw offset 281e3
va 428df6 = raw offset 281f6
Alternative TESTSIGNING method
Yet another way to solve the TESTSIGNING issue. We boot by configuring TESTSIGNING on in bcd. Now the intersting part is that we can patch the kernel so that when code integrity (ci.dll) is initialized, it will continue booting like as if TESTSIGNING was not set in the bcd. I've verified this because the watermark was not put on the desktop, at the same time as TESTSIGNING was shown in the registry under the key SystemStartOptions. I really don't recommend messing with the kernel, so you might want to stick with the other working solutions already posted. For those that like testing this, here is the patch located in the function SepInitializeCodeIntegrity. Change both conditional jumps to a jump short instruction (jmps);
Code:
PAGE:00572D42 call _SepIsOptionPresent@8 ; SepIsOptionPresent(x,x)
PAGE:00572D47 test eax, eax
PAGE:00572D49 jz short loc_572D4D
Change 7402 -> eb02.
Code:
PAGE:00572D5A call _SepIsOptionPresent@8 ; SepIsOptionPresent(x,x)
PAGE:00572D5F test eax, eax
PAGE:00572D61 mov eax, ds:_KeLoaderBlock
PAGE:00572D66 jz short loc_572D6B
Change 7403 -> eb03.
This way the kernel will always continue booting the system without testsigning, regardless of what you put in the bcd. The nice thing is you can have testsigning for the first part of the boot process, and choose to finalize the booting without testsigning. When testing kernels it could be a good thing to specify your custom kernel in the bcd with the kernel parameter (like "KERNEL mykernel.exe").
Now TESTSIGNING gets deactivated after the animation is played.
Modifying the text shown when animation is played can be done by hacking winload.exe:
1. To change the text "Starting Windows" you can open a resource editor and edit the "Message Table". Go for the last string.
2. To change the text "© Microsoft Corporation" at the bottom, you can search and replace the hex signature;
0000000000A90020004D006900630072006F0073006F0066007400200043006F00720070006F0072006100740069006F006E 000000
I found that the easiest way to remove both the copyright message and startup text is to set font size to 0. Replace the "B" with "0", and you will only have the animation present in the centre of the screen;
Code:
00443852 C745E40B000000 mov dword ptr [ebp-1Ch],0000000Bh
Placing the startup text at the very top of page can be done by replacing 20B with 000;
Code:
004437FE C745F40B020000 mov dword ptr [ebp-0Ch],0000020Bh
Changing the font size of the startup text is done here;
Code:
004439A6 C7432412000000 mov dword ptr [ebx+24h],00000012h
Changing "12" with "86" will create a huge text that will cover over the copyright message like this;
To change colour for copyright text look here;
Code:
0044384B C745DC7F7F7FFF mov dword ptr [ebp-24h],FF7F7F7Fh
and replace 7F7F7FFF with FF00FF00 to get purple coloured text.
And to change the startup text colour we must inject some of our own code. This is what I did to create light green coloured startup text:
old code
Code:
offset machine code assembler
.text:0044399C 832100 and dword ptr [ecx], 0
.text:0044399F 834B1CFF or dword ptr [ebx+1Ch], 0FFFFFFFFh
new code
Code:
offset machine code assembler
.text:0044399C E85F380200 call sub_467200
.text:004439A1 90 nop
.text:004439A2 90 nop
old code
Code:
offset machine code assembler
.rdata:00467200 00 db 0
.rdata:00467201 00 db 0
.rdata:00467202 00 db 0
.rdata:00467203 00 db 0
.rdata:00467204 00 db 0
.rdata:00467205 00 db 0
.rdata:00467206 00 db 0
.rdata:00467207 00 db 0
.rdata:00467208 00 db 0
.rdata:00467209 00 db 0
.rdata:0046720A 00 db 0
.rdata:0046720B 00 db 0
.rdata:0046720C 00 db 0
new code
Code:
offset machine code assembler
.rdata:00467200 832100 and dword ptr [ecx], 0
.rdata:00467203 C7431C00FF00FF mov dword ptr [ebx+1Ch], 0FF00FF00h
.rdata:0046720A C20400 retn 4
So the actual color code are stored at va 00467206 or raw offset 0x64A06.
Animation parameters:
Some animation parameters can also be tweaked (thanks to AlexYM). As the actual animation is played by the kernel we must patch it to modify these values.
The relevant function is ResFwpGetProgressIndicatorAnimation and this how it looks like in IDA for ntkrnlpa.exe;
Code:
PAGEBGFX:00748C97 mov eax, 0C8h
PAGEBGFX:00748C9C lea edi, [esi+0Ch]
PAGEBGFX:00748C9F mov dword ptr [esi], 1
PAGEBGFX:00748CA5 mov dword ptr [esi+4], 19Ch
PAGEBGFX:00748CAC mov dword ptr [esi+8], 11Ch
PAGEBGFX:00748CB3 mov [esi+10h], eax
PAGEBGFX:00748CB6 mov [edi], eax
PAGEBGFX:00748CB8 mov dword ptr [esi+18h], 0Fh
PAGEBGFX:00748CBF mov dword ptr [esi+1Ch], 69h
PAGEBGFX:00748CC6 mov dword ptr [esi+24h], 3Ch
Explanation after converting from hex to decimal:
Code:
At 00748C97 we find the frame's width and height as C8 = 200.
At 00748CA5 we find the x position of the frame as 19C = 412.
At 00748CAC we find the y position of the frame as 11C = 284.
At 00748CB8 we find the framerate (per sec) as 0F = 15.
At 00748CBF we find the total number of frames as 69 = 105.
At 00748CC6 we find the number of first unlooping frames as 3C = 60
So I made another stupid animation hack that is more annoying than elegant. Setting framerate to 78 (4e) and the number of first looping frames to 57 (39) will let you see the crystal balls start flying and when they are done (before they melt together) it will start over again. Really annoying to look at, especially when this repeates itself 19 times!
Modifying the coordinates of the animation can be testing while debugging in windbg with this script;
Code:
$$
$$ ==================================================================
$$ Script to move animation to different coordinates
$$ Made for version 6.1.7600.16385
$$ Will also work for SP1 when symbols are available.
$$
$$ usage from within a running debug session; $$><kernel.txt
$$ usage from commandline when launching windbg; -c "$$><kernel.txt"
$$
$$ by Joakim
$$
$$ ==================================================================
$$
bp nt!ResFwpGetProgressIndicatorAnimation+0x2D
g
$$ Original machinecode c746049c010000
$$ 9c01 is little endian of 19ch which in decimal is 412 and
$$ specifies the x position (from left)
eb eip c7 46 04 50 00 00 00
p
$$ Original machinecode c746081c010000
$$ 1c01 is little endian of 11ch which in decimal is 284 and
$$ specifies the y position (from top)
eb eip c7 46 08 50 00 00 00
g
$$ ==================================================================
$$ Animation now played in the upper left of your screen.
$$ ==================================================================
More kernel stuff: Distorted resoltion hack
I have done some tests and believe it is impossible to set screen resolution correctly to 800x600 and get animation at the same time. However I noticed it is possible to boot with 1024x768 and then force the kernel into believing the resolution is something different (must be smaller though, else it will crash) right before it will play the animation. With forced 800x600 it will look like flimmering stretched over the screen like this;
With 768x512 it looks like this;
To test this in windbg you can issue this command;
Code:
bp nt!BgpGetResolution "eb nt!BgInternal+0x8 00 03 00 00 00 02 00 00 00 03 00 00"
That is for 768x512 since 300h in decimal = 768 and 200h in decimal = 512. So the animation is played, but with a very distorted look. And sure funny for testing in virtual machines.
Patching the kernel (ntoskrnl.exe) on disk in a similar way translates into;
Code:
0073D61E 00030000 dd 00000300h
0073D622 90 nop 90h
0073D623 8B0D1ED67300 mov ecx,[L0073D61E]
0073D629 8908 mov [eax],ecx
0073D62B 8B0D3ED67300 mov ecx,[L0073D63E]
0073D631 894804 mov [eax+04h],ecx
0073D634 8B0D1ED67300 mov ecx,[L0073D61E]
0073D63A 894808 mov [eax+08h],ecx
0073D63D C3 retn
0073D63E 00020000 dd 00000200h
About BOOTMGR.XSL/OSLOADER.XSL
These are found inside bootmgr and winload.exe, and will influence on how things are displayed on screen when booting with different setups. It is basically a bunch of different frames, like for instance the menu presented when the BCD content is displayed. Thaimin explained the colour codes quite well;
Code:
RGBI 15 White
RGXI 14 Yellow
RXBI 13 Magenta
RXXI 12 Red
XGBI 11 Cyan
XGXI 10 Green
XXBI 9 Blue
XXXI 8 Dark Grey
RGBX 7 Light Grey
RGXX 6 Brown
RXBX 5 Dark Magenta
RXXX 4 Dark Red
XGBX 3 Dark Cyan
XGXX 2 Dark Green
XXBX 1 Dark Blue
XXXX 0 Black
This is the last page shown by bootmgr (after the boot menu), right before winload.exe takes over;
Code:
<xsl:template match="bootmgr-end-menu">
<osxml:text-mode-ui>
<body background-color="RGBX" foreground-color="XXXX">
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<p pad-left="25">FYI This is next page after boot menu (bootmgr)</p>
<br/>
<br/>
<p pad-left="22">You can put some text here if you want..</p>
</body>
</osxml:text-mode-ui>
The first page shown by winload.exe is;
Code:
<xsl:template match="osload-main">
<osxml:text-mode-ui>
</osxml:text-mode-ui>
</xsl:template>
You can tweak background and text like this (just another lame example);
Code:
<xsl:template match="osload-main">
<osxml:text-mode-ui>
<body background-color="RGBI" foreground-color="XXXX">
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<p pad-left="25">FYI This is the first page by winload.exe</p>
<br/>
<br/>
<p pad-left="22">You can put some text here if you want..</p>
</body>
</osxml:text-mode-ui>
</xsl:template>
The actual page shown when the animation is played is this;
Code:
<xsl:template match="osload-graphics">
<osxml:text-mode-ui>
<body foreground-color="XXXX" background-color="RGBX">
<br/>
<p pad-left="25">This is the animation page</p>
<textarea width="29" height="24"/><textarea name="status"/>
</body>
</osxml:text-mode-ui>
</xsl:template>
You can thus modify nearly everything in these frames.
Lately full image background has been solved (by thaimin) in winload.exe. A bitmap is added as rcdata 1 resource, and a new function was written to handle it. Proof;
Link to the documentation created by thaimin;
http://www.coderforlife.com/projects...mage-notes.zip Adding driver printing on top of bitmap
This last hack is currently not implemented in thaimins app. By following the next instructions you should be able to achieve something like this;
What we do is modify winload.exe's handling of the SOS switch. We can modify the code slightly inside OslDisplayInitialize (this is necessary), by changing this
Code:
.text:004061A6 push 26000091h (68 91 00 00 26)
to something invalid like
Code:
.text:004061A6 push 99999999h (68 99 99 99 99)
and basically deactivate the standard graphics handling if SOS switch is on. Specifically, it is the loaderblock passed on to the kernel that informs the kernel that SOS is not on, and thus allows for the animation to be played.
We need to make a jump to some custom code at 4014e0. This is inside OslpMain and necessary for the bitmap to replace the background xsl template. Original code;
Code:
.text:004014E0 lea eax, [ebp+arg_0] (8D 45 08)
.text:004014E3 push eax (50)
.text:004014E4 push ebx (53)
changed to;
Code:
.text:004014E0 jmp loc_4573B7 (E9 D2 5E 05 00)
and the custom code was placed right behind thaimins bitmapdrawing function;
Code:
.text:004573B7 call sub_457370 (new bitmap function)
.text:004573BC call sub_443823 (copyright)
.text:004573C1 lea eax, [ebp+arg_0]
.text:004573C4 push eax
.text:004573C5 push ebx
.text:004573C6 jmp loc_4014E5 (back to OslpMain to load SYSTEM hive)
Now and instead of having the whole screen covered with driver printings, we must reduce the size of the template that is displayed too. Here's my minimal "osload-sos" template;
Code:
<xsl:template match="osload-sos">
<osxml:text-mode-ui>
<body background-color="RXBI" foreground-color="XXXX">
<p pad-left="8" pad-right="8">
<textarea name="file-info" scroll="true" width="68" height="1"/>
</p>
</body>
</osxml:text-mode-ui>
</xsl:template>
As you may see, it's the height that will specify the number of lines displayed of driver printing.
Joakim Schicht
Note:
All disassemblies are based on x86 version 6.1.7600.16385. There's almost no difference in 32-bit vs 64-bit binaries. Some parts may change in future versions, but should not be too hard to figure out.
Link to thaimin's excellent tool that will do it all for you;
http://www.coderforlife.com/projects/win7boot/ And supporting both x86/x64 architectures! Some bugs are currently in the tool but I believe he will create a major update, hopefully in December.