Jump to content

Windows NT4 Extended Kernel


piotrhn

Recommended Posts

On 12/19/2020 at 8:19 AM, win32 said:

Big news for users of 32 bit software:

gimp.PNG?width=772&height=586

Having the ntdll and kernel32 functions in the same file has fixed the problems with importing certain ntdll functions, which means that 32 bit extended kernel development is going strong.

Indeed, the functions in this wrapper import ones that are present in NT 3.51 and up (discounting RtlSetLastWin32Error from XP, but that could be thrown in easily), making this set of Windows 7 functions backportable to much older OSes in theory.

Can you try expand NT4.0??  yunior600 tried but his project is dead... ;/

Link to comment
Share on other sites


7 minutes ago, piotrhn said:

Can you try expand NT4.0??  yunior600 tried but his project is dead... ;/

Since this is something you're very interested in, you could try starting this project yourself.

I simply don't have enough time to start something like this for NT4 and I assume win32 doesn't either.

Here's kernel32 with some simple modifications to get you started.

Link to comment
Share on other sites

4 minutes ago, Ximonite said:

Since this is something you're very interested in, you could try starting this project yourself.

I simply don't have enough time to start something like this for NT4 and I assume win32 doesn't either.

Here's kernel32 with some simple modifications to get you started.

ok , i want try. But dont know how:

  • add code to dll
  • add new imports
  • what tools use
  • etc...
Edited by piotrhn
Link to comment
Share on other sites

40 minutes ago, Ximonite said:

Since this is something you're very interested in, you could try starting this project yourself.

I simply don't have enough time to start something like this for NT4 and I assume win32 doesn't either.

Here's kernel32 with some simple modifications to get you started.

your modification doesnt work....

STOP c0000269 {invalid system DLL}...

kernel32.dll was relocated in memory...

ntdll.dll occupied the range of reserved addresses

Edited by piotrhn
Link to comment
Share on other sites

  • dencorso changed the title to Windows NT4 Extended Kernel
7 hours ago, piotrhn said:

ok , i want try. But dont know how:

  • add code to dll
  • add new imports
  • what tools use
  • etc...

Here's all the basics in one big post.

Tools:
IDA - A very good disassembler that handles Windows system files very well.
HxD - The hex editor I use. It doesn't matter which one you use, but you will need one.
PEMaker - Used for other general tasks, like adding imports and exports.
PETool - Another program made for general PE file editing. There's a few features in PETool that aren't done in any other program very well or at all.
Beyond Compare - For comparing lists of functions. I use Beyond Compare, but you can use whatever you prefer.
CFF Explorer - For editing the file header.

ida-view.png

Here is an IDA window. The main area is the code you're looking at. In the file, the code is stored as opcodes, which you can look at in a hex editor or the Hex View in IDA.

Changing a relative address:
A relative address is one where the difference between the current location and the location referred to is stored.
Example: At 77E16D22h, this instruction calls the function at 77E1580Eh. The data stored is the difference between 77E16D22h and 77E1580Eh, which is FFFFEAE7h.
The data is stored backwards in the file, so a difference of FFFFEAE7h would be stored as E7 EA FF FF.
If the location you want to make a function refer to already has a marker (example: loc_77E16D2B), then IDA can do everything for you. To do this, right click the address you want to change, and choose "Manual" in the drop-down menu. In the text field that says "Operand", change this to the address you want the instruction to refer to. This only works if another instruction refers to the address. If it doesn't, you will need to change the hex values directly. You can do this by going to the "Hex View" in IDA and pressing F2, then typing in hex values. Press F2 again to revert back to it's normal state.

Other general info: When writing hex values in text, like a post on MSFN, just writing the value may be confusing, so either add "0x" to the beginning or "h" to the end.

Changing an absolute address:
Changing an absolute address is pretty simple. Just change the hex values in the instruction from the old address to the new one. Remember that these addresses are stored backwards in the file.

This is all the info I know that could be very difficult to find noob-friendly info for. I ended up having my dad teach me this stuff, since he is familiar with IDA and uses it. Experimentation is the best way to learn this kind of stuff, so try stuff and see what happens.

Link to comment
Share on other sites

7 hours ago, Ximonite said:

I simply don't have enough time to start something like this for NT4 and I assume win32 doesn't either.

No, I don't either.

7 hours ago, piotrhn said:

ok , i want try. But dont know how:

  • add code to dll
  • add new imports
  • what tools use
  • etc...

To add code, you can do so with any good hex editor by writing it to the area where you want it. It can be tricky translating offsets to memory addresses though.

The current export table will probably have no room for expansion, which means you will have to use WildBill's PE Tool to create a new section before .rsrc that must fit the export table with up to a few thousand hexadecimal bytes for extra functions. BWC's PE Maker can be used to move (and add to) the export table. Then put the new code starting at the beginning of the old export table.


The new imports thing is tricky, especially with a DLL that already has an import table. BWC managed to import new functions using some special set of routines which call LoadLibraryA and GetProcAddress. It may be possible to export forward some functions, like calling ntdll.RtlSetLastWin32Error when it is not imported. (mind you this failed when I tried with NtQueryInformationProcess in Vista x64 shell32).

That is why I built completely new wrapper DLLs, where I can add new imports to a new import table at the end of the file using CFF Explorer (please let it make a new import table at first, otherwise it will put it in the reloc section which will kill the table if you ever add relocs) or Stud_PE. That and also I had trouble with importing certain functions in Vista x64 WOW64 so I had to call them directly.

There are also some special considerations for NT4, as it appears you will need to upgrade existing functions in gdi32/user32 (and probably in other files too) and the kernel-mode analog, win32k, plus add functions in ntoskrnl. I think you can do this with wrappers, by taking the original file, deleting the export table entry for the existing entry and then replacing it with a forward export to the wrapper (but even then, you will need to give the export table some breathing room). The wrappers do seem to work with ring3-to-ring0 "stub" functions, like Nt/Zw* series in ntdll.

As I also said, the functions exist in some very old NT (and even 9x) versions of Windows, but they may have changed over the years. So you could build extra wrappers with the updated functions and have my wrappers and existing Windows files refer to them instead of the outdated functions.

I grant permission to other kernel extenders to use my upcoming wrapper DLLs for other Windows OSes, and to modify them to allow them to run on their OSes, as long as I remain credited (perhaps add a tag in company name field in file properties like "created by win32, modified by piotrhn for improved functionality with NT 4).

Link to comment
Share on other sites

53 minutes ago, win32 said:

The new imports thing is tricky, especially with a DLL that already has an import table. BWC managed to import new functions using some special set of routines which call LoadLibraryA and GetProcAddress.

There's a way to do it without LoadLibraryA or GetProcAddress. This is what I do with everything cause I would rather spend my own time getting those functions in the import table than having the dll use a bunch of CPU clock cycles finding it. If it imports to the last file in the list, I can just add the import to the end. If it doesn't, here's what I do:

1. Shift every reference to everything in the import address table that's going to be moved by how much it will be moved. Example: The order of dlls imported is gdi32, kernel32, ntdll and I want to add an import to gdi32 (this is literally what I've been doing today in user32). I would shift every reference to every address in the import address table that corresponds to ntdll or kernel32 up by 4. I do this in HxD with the replace tool and I start at the very end and go up the table until I get through all the ntdll and kernel32 imports.

2. Rebuild the import directory in PEMaker. In my example, I would delete all the imports to kernel32 and ntdll, add the new gdi32 import, and readd all the kernel32 and ntdll imports with the addresses shifted up by 4.

Tip for Step 2: I make the PEMaker window as short as possible to reduce physical strain from moving the mouse from the table to the delete button as many times as I need, since that number of times is usually in the hundreds.

Note: Import hints don't needed to be correct when added back when doing this. They aren't essential for the file to work and if you care, ImportPatcher v29 can automatically correct them.

Edited by Ximonite
Added tip
Link to comment
Share on other sites

  • 1 month later...
On 1/25/2021 at 9:18 PM, piotrhn said:

its not my project

???

I definitely remember this being your project.

I just did a few quick things so you could look around in IDA and figure out the basics.

Edited by Ximonite
Link to comment
Share on other sites

  • 2 weeks later...
  • 3 months later...
On 12/21/2020 at 8:50 AM, Ximonite said:

Since this is something you're very interested in, you could try starting this project yourself.

I simply don't have enough time to start something like this for NT4 and I assume win32 doesn't either.

Here's kernel32 with some simple modifications to get you started.

Can you explain my, why your kernel32 crash with BSOD ?

STOP c0000269 {invalid system DLL}...

kernel32.dll was relocated in memory...

ntdll.dll occupied the range of reserved addresses

Edited by piotrhn
Link to comment
Share on other sites

If you are using it properly, perhaps the kernel32 modifications made it too big to fit at its preferred address. Relocation caused a conflict with ntdll. It needs to be trimmed down and stripped of relocation data.

 

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