Jump to content

Patching Windows 7 kernelbase.dll


dotexe1337

Recommended Posts

Hi, I have attempted to patch a function into KernelBase.dll with no luck. winload.exe was patched by changing every mov whatever, 0xc0000428 to mov whatever, 0x0 so that the kernel can load. It seems there is some kind of discrepancy somewhere across the chain, as whenever kernelbase.dll is patched, no matter what patches are applied, the system will encounter an access violation late in the boot process.

It's kind of strange because I ran the system through WinDbg, and when it crashes, the stack trace mentions that it's crashing when trying to call SetSystemPowerState, which isn't even part of KernelBase.dll, so the functions I'm patching in shouldn't even matter.

This is why I think there may be some kind of extra security to prevent kernel patches in Windows 7, compared to Vista.

Does anyone have an idea on what could be happening here?

Edited by dotexe1337
Link to comment
Share on other sites


How are you patching kernelbase.dll?

I have a virtual machine with a proxied user32.dll (i.e. user32.dll is written by me, which exports my added functions, and then proxies all original functions to "user33.dll" which is the original user32.dll). However, when I try to proxy kernelbase.dll, I get a bluescreen.

STOP: c0000142 {DLL Initialization Failed}
Initialization of the dynamic link library winsrv failed. The process is terminating abnormally.

Inspecting winsrv.dll, we can see that it imports kernel32.dll, which in turn imports kernelbase.dll. The original Kernelbase.dll itself only imports ntdll.dll. However, my patched kernelbase.dll imports kernel32.dll due to the Microsoft visual C runtime (MSVCR100.DLL), which is a BIG problem since kernel32.dll depends on kernelbase.dll (a cyclic dependency). In order to solve this problem, I statically linked the Microsoft visual C runtime into my kernelbase.dll, resulting in only a kernel32.dll import (no msvcr100.dll import) But this still requires kernel32.dll which is the big problem. So then, I fiddled with more compiler and linker settings in order to remove the kernel32 dependency as well - as pictured.

Then I went into my virtual machine and took ownership of kernelbase.dll and renamed it to krnlbase33.dll, and copied my kernelbase.dll to replace it. After rebooting, the system works.

594308768_kernelbaseredirect.thumb.png.bfa0f6c03296a52b0924b256c68ae75c.png

Note, that I haven't added any functions to kernelbase.dll, so I can't help you with your functions (unless you provide your source code). When you add your functions, keep in mind that you can NOT call any C runtime functions like printf, strlen, etc. You have to write your own implementations of those functions (which is easy). You also cannot call ANY function in ANY library that directly or indirectly depends on kernel32.dll. In practice, that means you can basically only call functions in ntdll.dll and the "original" kernelbase.dll (krnlbase33.dll in my example) - which is quite a lot of useful functions, actually. Note that "original" kernelbase.dll contains lstrcmp, lstrcmpi, lstrcpyn, and lstrlen in case you find those useful.

Hope that was helpful, ask me if you have any further questions.

Edited by vxiiduu
Link to comment
Share on other sites

  • 1 year later...
On 2/3/2022 at 8:22 AM, vxiiduu said:

How are you patching kernelbase.dll?

I have a virtual machine with a proxied user32.dll (i.e. user32.dll is written by me, which exports my added functions, and then proxies all original functions to "user33.dll" which is the original user32.dll). However, when I try to proxy kernelbase.dll, I get a bluescreen.

STOP: c0000142 {DLL Initialization Failed}
Initialization of the dynamic link library winsrv failed. The process is terminating abnormally.

Inspecting winsrv.dll, we can see that it imports kernel32.dll, which in turn imports kernelbase.dll. The original Kernelbase.dll itself only imports ntdll.dll. However, my patched kernelbase.dll imports kernel32.dll due to the Microsoft visual C runtime (MSVCR100.DLL), which is a BIG problem since kernel32.dll depends on kernelbase.dll (a cyclic dependency). In order to solve this problem, I statically linked the Microsoft visual C runtime into my kernelbase.dll, resulting in only a kernel32.dll import (no msvcr100.dll import) But this still requires kernel32.dll which is the big problem. So then, I fiddled with more compiler and linker settings in order to remove the kernel32 dependency as well - as pictured.

Then I went into my virtual machine and took ownership of kernelbase.dll and renamed it to krnlbase33.dll, and copied my kernelbase.dll to replace it. After rebooting, the system works.

594308768_kernelbaseredirect.thumb.png.bfa0f6c03296a52b0924b256c68ae75c.png

Note, that I haven't added any functions to kernelbase.dll, so I can't help you with your functions (unless you provide your source code). When you add your functions, keep in mind that you can NOT call any C runtime functions like printf, strlen, etc. You have to write your own implementations of those functions (which is easy). You also cannot call ANY function in ANY library that directly or indirectly depends on kernel32.dll. In practice, that means you can basically only call functions in ntdll.dll and the "original" kernelbase.dll (krnlbase33.dll in my example) - which is quite a lot of useful functions, actually. Note that "original" kernelbase.dll contains lstrcmp, lstrcmpi, lstrcpyn, and lstrlen in case you find those useful.

Hope that was helpful, ask me if you have any further questions.

Hello vxiiduu! I have tried your method, but I get the following issue:

image.png.2cd5252dec76e4c3f2dc8029d12c2d82.png

I also tried to redirect all apiset dll's to kernelba33.dll in kernel32.dll imports, but then it just tries to import these apiset dll's in something else and the cycle continues.

Do you know what's going on?

Thank you!

Link to comment
Share on other sites

15 minutes ago, dotexe1337 said:

Hello vxiiduu! I have tried your method, but I get the following issue:

image.png.2cd5252dec76e4c3f2dc8029d12c2d82.png

I also tried to redirect all apiset dll's to kernelba33.dll in kernel32.dll imports, but then it just tries to import these apiset dll's in something else and the cycle continues.

Do you know what's going on?

Thank you!

I got it working!!! Turns out the proxy exports were the issue.

Old exports (from VxKex):

image.thumb.png.41dac0836931edb21937be76fe878997.png

New exports (generated with: https://github.com/Xenov-X/DLL-Exports-Reverse-Proxy-Gen)

spacer.png

 

spacer.png

B-)

Edited by dotexe1337
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...