Windows 7: How to change boot animation in Windows 7

No you aren't. I am just busy...

DPI is dots per inch. I made the program automatically use straight-up pixels and ignore the DPI (which it uses by default if the file includes it).

Sorry I am bugging you too much!

I would like to announce that I have done the first successful full-background image! I was able to have a 24-bit BMP image drawn instead of the text and then the animation is drawn on top of that. I will not be including this in the next version of the program since it still needs much work, but the one after should have it.

The holdups for the next version are (in order of importance):

• Winresume locking up
  • 32-bit locks up right after text is draw, before animation
  • 64-bit locks up after the animation and it is done resuming, on a black screen
• Need to fully test long copyright texts
• The problem that causes random people to enter System Restore

@joakim
This message will be quite technical, so I decided to separate it out.

The tests were done in Windows 7 32-bit, pre-SP1, with TESTSIGNING enabled on both {bootmgr} and {current} and boot debugging on {current}. I used no other hacks besides the new function.

As you suggested, I switched the whole function over to using RC_DATA 1 in winload.exe instead of RC_DATA 2 in bootres.dll. The changes here were to use "and eax, 0; and ecx, 0" instead of "mov eax, ...; mov ecx, ...". And changing the id to 1 instead of 2. This will have the added benefit of allowing different images for boot-up and resuming.

I found that there were numerous issues with the code I sent you since I didn't understand how to write a function from scratch in assembly. What I did to make the function work properly was continually change the bytes, have IDA re-deassemble the file, and then use Hex-Rays to decompile my function. I tweaked it until the decompiled function looked as expected.

There is still one major issue however. The call to the new function is "messed up". But it shouldn't be... In the file it looks fine (and I checked the actually file being run) [E8 87 5F 05 00] but while debugging it changes to [E8 87 2F 18 00]. No other function call is doing weird things. I finally got around this by using WinDbg to change the code back to [E8 87 5F 05 00] while it was already running and it worked.

What do you think about that last issue? Is it something with re-basing the code when it is loaded? The base specified in the file is 0x400000 but the file is loaded at 0x52D000 when actually run. The difference there (0x12D000) is the exact difference that is introduced... The reason it may only be affecting that one spot is that the code it is replacing is an absolute memory reference. So maybe the relocs table has to be updated...

@thaimin: I am inquistive are the holdups for the next version should be ironed out if one thing is working then all should work?
Good job, thaimin!

Thanks for giving such an utterly excellent example of a trial & error method. I never thought of this.

I also ran into this issue and ended up hardcoding the "rebased" memory location at certain places (not all of them actually). I never really understood why only certain parts needed this, but I managed to get it work, at least in terms of making the call to the right location, and continue execution as expected. It certainly looked weird. However my code (or mostly yours) about the bitmap drawing didn't work at the time, so no image was drawn. But the system booted fine anyway. If you can send me a sample with a working bitmapdrawing, I'll try to fix the adresses. But believe me, it is not difficult, and I feel you are way more skilled than me.

I will also be extremely busy at work in the next days, but I will try to squeze in a few minutes. If not tonight, then it must be next week sometime.

Joakim

@joakim
I did just a little bit of additional research and got it to not relocate it! The PE file has a section called ".reloc" and a data directory IMAGE_DIRECTORY_ENTRY_BASERELOC (both should point to the same place in the file). It lists all the places where relocations need to occur. Very near the beginning was the one we were looking for. Changing it to 0s made it ignored (whenever the first 4 bits are 0, the entire relocation entry is ignored).

You can read more about them at Peering Inside the PE: A Tour of the Win32 Portable Executable File Format in the section "PE File Base Relocations" and Inside Windows: An In-Depth Look into the Win32 Portable Executable File Format, Part 2 in the section "Base Relocations". I used PE View (WJR's PEview(PE/COFF File Viewer), xlatHinc, M(Mandelbrot Set), Awpm) to look at the file and find it.

I zeroed it out, retested, and voilà it works! I will have to add a little something to my program to automatically search for and zero out overwritten relocations.

I will send you an updated document soon with how this all finally worked. As a note there will likely be some changes to get it to work in 64-bit.

Thanks! I thought it was pretty clever too, and actually went pretty quickly. Some changes I could do right in IDA without re-disassembling (as long as they were the same length assembly instructions).

@RBCC
Each one is its own thing. I may have fixed the 32-bit winresume issue just I haven't tested. I have no idea about the 64-bit winresume issue at the moment. The long copyright testing I am quite certain works, I just haven't tested it since I changed my patching system and got SP1 working. The last one I have one idea left to test, and hopefully that will be it! Otherwise I will release it with that issue still there. All in all, this isn't too big of problems to work out, and hopefully this weekend, time permitting, I will release it.

Very nice! Thanks a lot! I've read the book/article more than once in the past. But I guess it helps to re-read it at certain intervals whenever your knowledgebase has increased and you're able to digest more of the info.

Could you also attach a sample winload.exe at the same time (I barely have any time left at all, and will thus not have time to implement the new code before debugging)?

Joakim

Thaimin:

Will this be in form of a alpha ie alpha10? Or could you release as a patch for 9? RBCC

@RBCC
This will be a new program: alpha 10. Alpha 9 (the current) and before have no means to be 'patched'. Alpha 10 has minimal means of being patched (only its knowledge of where to look to replace things in the system files). Any additional work (many of the things I am and will be working on) will require completely new programs. If you haven't noticed you download a single program file, it does not install anything... Please think about things before you ask.