If you for some reason are tired of the same boring screens while booting your Windows 7 based stuff, then look here for how to modify more or less everything during the boot process; http://www.sevenforu...indows-7-a.html
This includes modifications to the boot menu, boot animation and several "pages/rectangles" in between or after. It includes hacks for bootmgr, winload.exe, bootres.dll, and the kernel itself. Despite the frightening number of posts in the thread, at least the ones by me and "thaimin" are good reading.
Although he (thaimin/Jeff Bush) made a program to automate much of it, it is still interesting to read the details on how to manually do it yourself.
Lately I tried to add bitmap-drawing functionality to bootmgr (as behind the boot menu), but still not completely resolved..
If you ever wondered how bootmgr is compressed (introduced in Vista sp 1 or 2) or how to decompress it, then the answer is in that thread. (you can actually boot it in either a compressed and uncompressed state).
But probably not every detail made its way into that thread, in which case you may just ask, if it's not already answered there..
Customized behaviour of the boot process
Started by
joakim
, Apr 09 2011 11:22 PM
2 replies to this topic
#1
Posted 09 April 2011 - 11:22 PM
#2
Posted 25 April 2011 - 12:02 PM
Updated the referenced thread with information on how to make custom driver printing on top of a bitmap plus animation. This is how it looks;
http://www.youtube.com/watch?v=r19QOEHL-YE
And details;
Information based on x86 binary version 6.1.7600.16385
http://www.youtube.com/watch?v=r19QOEHL-YE
And details;
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;
r19QOEHL-YE
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.text:004061A6 push 26000091h (68 91 00 00 26)
to something invalid like.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;.text:004014E0 lea eax, [ebp+arg_0] (8D 45 08) .text:004014E3 push eax (50) .text:004014E4 push ebx (53)
changed to;.text:004014E0 jmp loc_4573B7 (E9 D2 5E 05 00)
and the custom code was placed right behind thaimins bitmapdrawing function;.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;<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.
Information based on x86 binary version 6.1.7600.16385
#3
Posted 25 April 2011 - 05:49 PM
Also added some more kernel tweaks as well as relating windbg stuff;
Still on the same executable arch and version.
Modifying the coordinates of the animation can be testing while debugging in windbg with this script;
$$ $$ ================================================================== $$ 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;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;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
Still on the same executable arch and version.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users