I'm new to this business and I have a difficult task. I need to write a program with which it would be possible to get the data of a certain process. This process is in a file .dmp, which is a full RAM dump. As far as I know, every process in Windows OS has an EPROCESS structure. So, having received this structure, I will be able to find the data of this process. Are there any libraries or functions that can facilitate this task? For example, in C++ or Python?
Related
I'm trying to research information about how to implement the memory management system in a DBSM. I know the theoretical part, but can't find anything about bypassing the memory management system in Linux, windows nor mac OX.
I'm trying to implement an efficient DBMS myself for fun. Which should be able to run on any common OS. In Database Systems The complete book, they discus the importance on fitting the relations/tables in adjacent sectors/blocks on hardware for faster read/write. But i can't seem to find anything when crawling the web. Is there a way to bypass the memory management system, such that I can write to specific locations on disk in such that the data saved there are placed on continuously blocks and so that the file system can recognize the data as a file?
I know that this is not a general coding question.
I'm used to write in C, C#, F#, ML, Python and a little gnu assembly.
For clarification I do not mean which DBMS should I use, I'm trying to implement the the DBSM myself.
I was dumping a pe file out of a process and was wondering how it had found the pe file in memory.
At first I thought that it was looking for the DOS string but the software states that it can find pe files which are not loaded according to the documentation so that is out of the question.
There are many ways to find loaded modules in memory if they are loaded in the normal way using the Windows OS Loader or LoadLibrary because the Process Environment Block or PEB contains a pointer to the PEB_LDR_DATA structure named 'Ldr' which contains a linked list of all loaded modules. This is the same list of loaded modules which the Windows OS uses when using the API ToolHelp32Snapshot.
If the the module is removed from this Ldr.InMemoryOrderList or perhaps loaded using a manual mapping routine, this won't be possible, in which case you could detect the module by scanning for the predictable PE header in memory.
If the PE Header is deleted and the module is not in the linked list, which is possible then this becomes more difficult. You would need to use some sort of heuristics to detect the somewhat predictable nature of a PE file such as a DLL.
For instance, you have the PE file for the process, so you know what imports & relocations are done You know what modules are loaded and where, so if you find memory pages outside of these locations which have page protections set to executable, then you can be pretty confident that these belong to hidden or at least unknown modules.
Here are 2 excellent repos which may shed some light on the topic Hollows Hunter & PE-Sieve
I know system call's uses is to communicate between use-level and kernel-level
So, Does that mean I can write kernel memory with system call?
e.g. write() is used to write kernel memory
But if what I think is available, It also relate big-security problem?
If I can't, why?
Let's break your questions down one by one.
Yes you can write to kernel memory via system calls directly if you implemented one that allowed writing to arbitrary locations in memory. Whether or why you would want something like this is another question. Something like this would pose a huge security risk. For example, any process can elevate their privileges or install rootkits in the kernel easily using your system call.
However, Linux does have an interface for reading and writing to kernel memory. Have a look at /dev/kmem. It allows you to open kernel memory as a 'file', seek around and read and write to it.
I am starting to learn the assembly programming language and want to know how does Windows execute assembly programs? Does Windows also use the same procedures for executing .exe files?
At this point I am having a hard time focusing on learning the assembly programming language while constantly thinking of what happens in the background.
I am also looking for a book to get a better and deeper understanding of Windows internals and how general operating systems perform tasks such as the one stated above. Any help(terminology used to describe the procedure) or reference to external resources is appreciated!
After you assemble your program, it becomes a normal executable, and Windows executes it like it would any other native executable.
A native executable contains machine code, which can be executed by the CPU directly. The operating system essentially just loads it into memory, sets up a new process, and starts that process running at the start of the program.
I would like a low-overhead method of monitoring the I/O of a Windows process.
I got several useful answers to Monitoring certain system calls done by a process in Windows. The most promising was about using Windows Performance Toolkit to get a kernel event trace. All necessary information can indeed be pulled from there, but the WPT is a massive overkill for what I need and subsequently has a prohibitive overhead.
My idea was to implement an alternative approach to detecting C/C++ dependency graphs. Usually this is done by passing an option to the compiler (-M, for example). This works fine for compilers and tools which have such an option, but not all of them do, and those who do often implement them differently. So, I implemented an alternative way of doing this on Linux using strace to detect which files are opened. Running gcc (for example) in this way has a 50% overhead (ballpark figure), and I was hoping to figure out a way to do this on windows with a similarish overhead.
The xperf set of tools have two issues which prevents me from using them in this case:
There is no way to monitor file-I/O events for a single process; I have to use the kernel event trace which traces every single process and thus generates huge amounts of data (15Mb for the time it takes to run gcc, YMMV).
As a result of having to use the kernel event trace, I have to run as administrator.
I really don't need events at the kernel level; I suppose I could manage just as well if I could just monitor, say, the Win32 API call CreateFile(), and possibly CreateProcess() if I want to catch forked processes.
Any clever ideas?
Use API hooking. Hooking NtCreateFile and a few other calls in ntdll should be enough. I've had good experience using easyhook as a framework to do the hooking itself - free and open source. Even supports managed hooking (c# etc) if you wanted to do that. It's quite easy to set up.
It's at located at http://easyhook.codeplex.com
Edit: btw detours does not allow 64 bit hooking (unless you buy a license for a nominal price of 10,000USD)
EasyHook does not allow native hooks across a WOW64 boundary. It allows managed hooking across WOW64 boundaries though.
I used Microsoft's Detours in the past to track memory allocations by intercepting particular API calls. You could use it to track CreateFile and CreateProcess.
It seems like Dr. Memory's System Call Tracer for Windows is exactly what I was looking for. It is basically a strace implementation for Windows.