Jump to content











Photo
- - - - -

Customized behaviour of the boot process


  • Please log in to reply
2 replies to this topic

#1 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 09 April 2011 - 11:22 PM

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..

#2 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

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;

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 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 25 April 2011 - 05:49 PM

Also added some more kernel tweaks as well as relating windbg stuff;

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;

Posted Image

With 768x512 it looks like this;

Posted Image


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