Welcome to Windows 7 Forums. Our forum is dedicated to helping you find solutions with any problems, errors or issues you are experiencing with Windows 7. The Windows 7 forum also covers news and updates and has an extensive Windows 7 tutorial section that covers a wide range of tips and tricks.
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!
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. Use the tool and test certificate as packaged here;
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.
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.
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;
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
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;
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;
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;
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>
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;
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;
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;
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.
Last edited by joakim; 04-25-2011 at 09:13 AM..
Reason: Added driver printing instructions (SOS switch) and some windbg tricks
AWESOME! Thanks so much. I am glad that this has been figured out and that any assistance I provided may have helped. The trick with cleaning up the old table is nice! I was just signing over it (it allowed me, but stuff still wasn't working).
AWESOME! Thanks so much. I am glad that this has been figured out and that any assistance I provided may have helped. The trick with cleaning up the old table is nice! I was just signing over it (it allowed me, but stuff still wasn't working).
I had a hard time myself trying to re-sign the file, until I figured out the small trick. And I was about starting to bang my head against the wall in frustration..
@taimin
It would still be nice if you wanted to publish the tool you talked about earler on, the automatic signer.
@marcusj0015
The way I described is the hard way, the way you must do if you do not have a great pe-editor. If you have for example PE Explorer, which is one of the best, you will definetely have the features included, and there is no need to use a hex editor. I have never used a x64 based pe editor, so I don't know.
@WaxyChicken
I will not distribute a ready made bootres.dll. Re-installing sounds a little bit overkill.. Try it out in virtual machine first - always! The bcd store must also be adjusted on x86 architecture, otherwise a major security bug is present.
@all
Adding an animation to bootres.dll will likely slow down the boot process, so I would actually advise against it. The stupid animation in the first post must not be implemented on any machine that a person who is sensitive to epileptic seizures are operating..
ok this is annoying me you didnt start the project all you did was talk alot in the other thread and you come over here and act like you were the person that figured all of this shit out.then you shit on all the people that had hope for this to be even partitally understandable theres not even x64 support! how about we all just pull this thread until we have a program that can actually handle all of thisfrom one program WITH AN INTERFACE!!!!!seriously this isnt even half baked and your releasing iti say we pull it and write a program to handle all of the aspects of bootres modding