Windows Kernel: Retrieving function addresses inside modules - windows

I am trying to call a function in the kernel that is located in the win32kfull.sys module.
I got the base address of the module using ZwQuerySystemInformation.
Now I want to find out the offset of the NtUserSendInput function located in the win32kfull.sys module.
When I open win32kfull.sys in IDA Pro and open the function, I get two addresses:
Unfortunately I don't know how to add the offsets to the base address of win32kfull.sys to get the function address.
I would be grateful if someone could explain to me how I could proceed now.

Since NtUserSendInput is an exported function, which means that the PE format of the image (specifically export directory) will let you know the address of the function if you parse it correctly.
This is a better solution, getting the offset out of IDA Pro would give you version specific address, which means that i would have to get the offset for each build of win32kfull.sys and each time there is new version you gonna have to update your driver.
So, if you have the base address of win32kfull.sys you can treat it as the start address for the PE structure and parse it, there are plenty of tutorials online about how to do that.

Related

Virtual Address assigned to an imported function

Consider an instruction like CALL DWORD PTR 44244100 that imports and uses a DLL function within an assembly program.We know the address used by the instruction is a Relative Virtual Address (RVA).
1.So why do I reach another VA value in the Thunk value field of the LordPE software when I trace that piece of code by it?
2.Whether DLL's such as User32 or Kernel32 always is loaded at a specific VA or not necessarily?
If not so how does Loader recognize which DLL the address mentioned above belongs to? by searching in Name Table?!
I mean this address is invariant,so if the loaded dll's location is fixed too,then another VA should be assigned to this address first.
Thanks all.
I don't understand the first question.. If you mean thunk as for function imports those aren't RVAs, those are flat addresses. Also address used by instruction in case of code addressing is always relative to current instruction pointer value. RVAs are only used by loader pretty much (and functions like LoadLibrary, GetProcAddr and these).. I think. x86 Processor does not know the concept of RVA that's for sure. Maybe you knew that, it wasn't very clear to me, if that's the case, sorry for lecturing.
Question two! No! It is not fixed! The loader actually goes through import table of your exe and fills in placeholders. Fixed load addresses are no more a thing since windows xp sp3. Hope this helps. If not, this helped me when I was little potato https://msdn.microsoft.com/en-us/library/ms809762.aspx

How to get address of system call entry point?

When a system call is invoked from 64-bit userspace to 64-bit kernel, syscall table is accessed from arch/x86/kernel/entry_64.S, from the system_call assembly entry point. How can I get the virtual/physical address of this "system_call()" routine?
In other words, I want to know the address of entry point used by all system calls. I tried looking at kallsyms file but couldn't find it there. Perhaps, it has another name in kallsyms?
Reference: https://lwn.net/Articles/604287/
What do you need this for? Are you sure you were inspecting kallsyms of the same kernel which was used in the article?
Figuring out what the func got renamed to is left as an exercise for the reader.

Process injections. Windows

I know how to inject my code into other process using system calls - just get module handle using GetModuleHandle, and get proc address using GetProcAddress. By that address I can write jump instructions to my function.
But I need to inject into function of target executable. I have function's offset inside PE, know section. How to calculate needed addres in runtime to write jump instructions?
Thanks!
The module handle is the address of the start of the module, so if you know the offset you can just add them together.

Jump to App from custom bootloader in TMS320 digital media processor

I am working on a boot loader for TMS320DM6437. The idea is to create 2 independent firmware that one will update another. In firmware1 I will download firmware2 file and write it to NOR flash in a specified address. Both firmware are stored in NOR flash in ais format. Now I have two applications in flash. One is my custom boot loader and the second one is my main project. I want to know how I can jump from the first program to the second program located at a specified address. I also expect information about documents which may help me to create custom bootloader
Any recommendations?
You can jump to the entry point. I'm using this approach on TMS320 2802x and 2803x, but it should be the same.
The symbol of the entry point is c_int00.
To get to know the address of c_int00 in the second application, you have to fix the Run-Time Support (RTS) library at a specific address, by modifying the linker command file.
Otherwise you can leave the RTS unconstrained, and create a C variable (at a fixed address) that is initialized with the value of cint_00. Using this method your memory map is more flexible and you can add, togheter with the C variable, a comprehensive data structure with other information for your bootloader, e.g. CRC, version number, etc.
Be carefull with the (re)initialization of the peripherals in the second application, since you are not starting from a hardware reset, and you may need to explicity reset some more registers, or clear interrupt requests.

Windows PE detemine entry point virtual address

I am examining a Windows executable with 'PE Editor' which displays the Entry point as 0x15B8, how do we determine this entry point's address as a virtual address?
The entry point is stored relative to the load address of the module.
The module can state its preferred address by setting the ImageBase field in the IMAGE_OPTIONAL_HEADER (see this page). However, the OS is free to select another address, either because the preferred address is in use, or, these days, because of ASLR.
I'm not sure what environment you're running this on, but if you're doing this with a live running program: It's an implementation detail, but on NT you can cast an HMODULE into a pointer and that is the load address of the module. You can also read PE headers based on that. So for example you can add the AddressOfEntryPoint member to the address of the HMODULE and find an entry point... If rather than load time info, you'd like something like a byte offset into the file, you'll have to parse the section headers to find where in the file it goes.

Resources