I have a question about calling the routine ZwReadVirtualMemory from my driver. I noticed it is not exported by ntokskrnl after dumping the EAT. How and where can I find the virtual address for this routine?
Is it located in the ssdt? if so, does not patchguard prevent me from reading there anyway? Or is that only for writing.
Also, this is for windows 7 x64.
Thanks!
ZwReadVirtualMemory is not exported from kernel. But you can find it in SSDT. Use ntdll trick. Don't worry about PatchGuard. It prevents only from code modification, reading is ok.
Also take into consideration that ZwReadVirtualMemory is not the only way to read virtual memory.
Bear in mind that SSDT on win 64 doesn't hold pointers to functions. It holds offsets which are relative to the start of nt!KiServiceTable. Also one of the viable ways of finding SSDT is to perform some sort of pattern scan in order to locate. Basically for 64 bits just forget with tinkering freely with the SSDT. For more information read this
Furthermore - patchguard is just for modification of system-critical components.
Related
Is it possible to build a position independant code for windows ?
I am not talking about a dll, i am talking about an executable (PE).
What i want to do is that functions (main for example) which are in the program should be mapped at a different memory address between 2 executions.
Thanks
You should read up on the image base relocation directory in a PE file. I was wondering the same thing you are asking now a while back. From the research I had done I couldn't find any compiler that generates completely base independent code. I ended up writing my program entirely in x86 asm with some tricks to load strings etc independent form the address. I can tell you its not worth the trouble. Just remap all the addresses to your target location.
I suggest you start reading this
https://msdn.microsoft.com/en-us/library/ms809762.aspx
You should also check out Icezilon's (not sure how you spell his name) tutorials. They're very helpful
As a part of understanding virtualization, I am trying to extend the support of KVM and defin a new instruction. The instruction will use previously unused opcodes.
ref- ref.x86asm.net/coder32.html.
Now, lets say an instruction like 'CPUID' (which causes a vm-exit) and i want to add a new instruction, say - 'NEWCPUID', which is similar to 'CPUID' in priviledge and is trapped by hypervisor, but will differ in the implementation.
After going through some online resources, I was able to understand how to define new system calls, but I am not sure about which all files in linux source code do I need to add the code for NEWCPUID? Is there a better way than only relying on 'find' command?
I am facing below challenges:
1. Which all places in linux source code do I need to add code?
2. Not sure how this new instruction can be mapped to a previously unused opcode?
As I am completely new to this field and willing to learn this, can someone explain me in short how to go about this task? I will need the right direction to achieve this. If there is a reference/tutorial/blog describing the process, it will be of great help!
Here are answers to some of your questions:
... but I am not sure about which all files in linux source code do I need to add the code for NEWCPUID?
A - The right place to add emulation for KVM is arch/x86/kvm/emulate.c. Take a look at how opcode_table[] is defined and the hooks to the functions that they execute. The basic idea is the guest executes and undefined instruction such as "db 0xunused"; this is results in an exit since the instruction is undefined. In KVM, you look at the rip from the VMCS/VMCB and determine if it's an instruction KVM knows about (such as NEWCPUID) and then KVM calls x86_emulate_instruction().
...Is there a better way than only relying on 'find' command?
A - Yes, pick an example system call and then use a symbol cross reference such as cscope.
...n me in short how to go about this task?
A - As I mentioned in 1, first of all find a way for the guest to attempt to execute this unused opcode (such as the db trick). I think the assembler will trying to reject unknown opcodes. So, that the first step. Second, check whether your instruction causes an vmexit(). For this, you can use tracing. Tracing emits a lot of output, so, you have to use some filter options. If tracing is overwhelming, simply printk something in vmx_handle_exit (vmx.c). Finally, find a way to hook to your custom function from here. KVM already has handle_exception() to handle guest exceptions; that would be a good place to insert your custom function. See how this function calls emulate_instruction to emulate an exception to be injected to the guest.
I have deliberately skipped some of the questions since I consider them essential to figure out yourself in the process of learning. BTW, I don't think this may not be the best way to understand virtualization. A better way might be to write your own userspace hypervisor that utlizes kvm services via /dev/kvm or maybe just a standalone hypervisor.
I have foo.exe which is using some of Windows API functions. I want to get memory addresses of those functions, how do I do that? Any software available which I can use?
Note, that I am looking for non-programatically way of doing that.
Thanks
I am looking for non-programatically way of doing that.
Either this is not possible or it doesn't make any sense. Likely both.
You see, in order to call one of the Windows API functions, a program must import it from the DLL that contains the function of interest. This requires that DLL to be loaded into the address space of that program's process. And because each process has its own address space, each process gets its own unique instance (or copy) of the DLL. That means that the "memory address" of functions provided by DLLs is going to be different in each process.
Retrieving this information non-programmatically just doesn't make sense. Even if you could get it, it wouldn't do you any good.
I could probably provide better advice if you edited your question to explain what you're hoping to accomplish, rather than just asking about the approach you already settled upon.
The addresses of exported functions can be different for every process that loads the DLL. The GetProcAddress function can tell you what they are for your process.
I know that generally the object file has code, data, heap and stack sections.
But I want to know how this is arranged in windows executables and Linux executables.
I searched on internet and found some structure.
I understood .text is for code and .data is for global variables.
I want to know here is the stack and heap in both Linux and Windows platform?
Can anybody tell me the executable file structures??
Thanks in advance...
This is the specification that Microsoft has released:
http://msdn.microsoft.com/en-us/windows/hardware/gg463119
Also this is a good reading on the subject:
http://msdn.microsoft.com/en-us/magazine/cc301805.aspx
EDIT:
Stack/Heap are in-memory structures which are created/modified during run-time so in essence they are not in the file itself - they can't be. Think of them as a special place in memory where each and every program can store run-time data and by run-time data I mean variables. function invocations, return values and all the nitty-gritty stuff that are hapening on the low level.
I am writing a scriptable game engine, for which I have a large number of classes that perform various tasks. The size of the engine is growing rapidly, and so I thought of splitting the large executable up into dll modules so that only the components that the game writer actually uses can be included. When the user compiles their game (which is to say their script), I want the correct dll's to be part of the final executable. I already have quite a bit of overlay data, so I figured I might be able to store the dll's as part of this block. My question boils down to this:
Is it possible to trick LoadLibrary to start reading the file at a certain offset? That would save me from having to either extract the dll into a temporary file which is not clean, or alternatively scrapping the automatic inclusion of dll's altogether and simply instructing my users to package the dll's along with their games.
Initially I thought of going for the "load dll from memory" approach but rejected it on grounds of portability and simply because it seems like such a horrible hack.
Any thoughts?
Kind regards,
Philip Bennefall
You are trying to solve a problem that doesn't exist. Loading a DLL doesn't actually require any physical memory. Windows creates a memory mapped file for the DLL content. Code from the DLL only ever gets loaded when your program calls that code. Unused code doesn't require any system resources beyond reserved memory pages. You have 2 billion bytes worth of that on a 32-bit operating system. You have to write a lot of code to consume them all, 50 megabytes of machine code is already a very large program.
The memory mapping is also the reason you cannot make LoadLibrary() do what you want to do. There is no realistic scenario where you need to.
Look into the linker's /DELAYLOAD option to improve startup performance.
I think every solution for that task is "horrible hack" and nothing more.
Simplest way that I see is create your own virtual drive that present custom filesystem and hacks system access path from one real file (compilation of your libraries) to multiple separate DLL-s. For example like TrueCrypt does (it's open-source). And than you may use LoadLibrary function without changes.
But only right way I see is change your task and don't use this approach. I think you need to create your own script interpreter and compiler, using structures, pointers and so on.
The main thing is that I don't understand your benefit from use of libraries. I think any compiled code in current time does not weigh so much and may be packed very good. Any other resources may be loaded dynamically at first call. All you need to do is to organize the working cycles of all components of the script engine in right way.