Title pretty much sums it up. I just found out about this function and well, it surprised me it existed as immediately the possible security consequences sprung into mind.
Why is there such a function? I understand that for debugging something like this is more or less necessary but allowing it for all processes seems like a big security problem.
Am I missing something?
If the function is needed to write a debugger, then the function must exist, it's as simple as that. The hProcess argument must have been opened with sufficient privileges to write into the process, and it will be difficult for malware to do that.
If you read the MSDN documentation for WriteProcessMemory you will see,
hProcess [in]
A handle to the process memory to be modified.
handle must have PROCESS_VM_WRITE and PROCESS_VM_OPERATION access to the process.
So you already have to have access to the process you want to modify. So the users can't mess with each other's processes using this function.
Related
I'm researching into game anti-cheat solutions so I can get a better grasp at how such security works. An approach used by many cheats is to use OpenProcess to open a process handle so they can use ReadProcessMemory to directly read data:
var procHandle = Kernel32.OpenProcess(
ProcessAccessRights.MemoryRead,
false, process.Id
);
(snippet from a C# game cheat)
This can be used to, for example, retrieve the positions of various entities in the game world, without needing to inject any kind of DLL; cheats that use this approach are called "external" cheats (as opposed to "internal" cheats that inject a DLL into the process).
In my anti-cheat engine, I want to detect such operations. I haven't been able to find any WinAPI methods that would call any kind of callback when a new kernel process handle is opened. If such method doesn't exist, I'm willing to use polling and enumeration (go through every single process handle to see if it's referring to my game process, and if it has the PROCESS_VM_READ access right. However, I couldn't find a function to get all such handles as well.
I'm pretty sure anti-cheat engines like Valve Anti-Cheat or BattleEye use this kind of detection; so, I think this would be possible from user-mode, since VAC does not install any kind of kernel driver, from my knowledge. If that is also not possible, a notification to when ReadProcessMemory is called would also work, but I doubt that's possible.
Any reference to a WinAPI method in the documentation that can accomplish such task would be appreciated, or a snippet ( in any language that can use WinAPI, I don't really mind :) ) that would demonstrate such behavior.
I am studying about the windows programming, and i have some question.
I saw a security module that defends memory data.
if one process is going to change other process memory, it detects and turns off the process.
This is often used in anti-cheat engines in games or bank application programs(i live in Korea, so i think this is the best example of this. Almost every on-line games or bank application has self-defence algorithm.)
My question is, is there any APIs or functions that detects about this?
thanks.
P.S.
i can make an example,
if 0x01000000 memory data is 'A', some different process changed it to 'B'.
when i first thought about this, i thought that i have to make a thread to check the data and if it changes, turn off the process.
but i think this is not a good idea. any suggestions?
General answer to your question: no, there are no such API or functions.
But there are different methods where you can achieve same result.
1. Api hooking. You can Hook functions in system (such as WriteProcessMemory) and then check if somebody trying to change something in your process. More on this here.
2. Debugging. You can use debugging breakpoints on functions or memory change.
There's an API that allows you to monitor writing operations into a piece of the specific memory area.
UINT GetWriteWatch(
DWORD dwFlags,
PVOID lpBaseAddress,
SIZE_T dwRegionSize,
PVOID *lpAddresses,
ULONG_PTR *lpdwCount,
LPDWORD lpdwGranularity
);
When the API detects any writing operations, it appends the writing addresses into the arrays that you provided as the parameter of the API, until your array is full.
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.
Anyone knows anything about running executable from memory in OSX?
anything like this:
char *exeFile[size];
loadFromFile(exeFile, "/path/to/data");
execute(exeFile);
I want do that for security reasons. for example It is possible to encrypt exe and decrypt it before launch.
Well, yes, you can do it but its complex. I don't have access to working code right now but I do know others that are/have used it. The key is "NSCreateObjectFileImageFromMemory()", which is deprecated, but that said a few big apps like Skype reputed use it so its probably not going to disappear anytime soon (YMMV).
You have to allocate a memory buffer that's a multiple of the pagesize with vm_allocate. Copy the mach-o executable of the same architecture as the current process to there. Call NSCreateObjectFileImageFromMemory() which returns an object image. Then call successively NSLinkModule, NSLookupSymbolInModule and NSAddressOfSymbol. That last one gets you an actual function pointer to call.
This should give you most of what you need to know, and if you search you may find code that does it too. Good luck!
The MSDN states in its description of ReadFile() function:
If hFile is opened with FILE_FLAG_OVERLAPPED, the lpOverlapped parameter must point to a valid and unique OVERLAPPED structure, otherwise the function can incorrectly report that the read operation is complete.
I have some applications that are violating the above recommendation and I would like to know the severity of the problem. I mean the program uses named pipe that has been created with FILE_FLAG_OVERLAPPED, but it reads from it using the following call:
ReadFile(handle, &buf, n, &n_read, NULL);
That means it passes NULL as the lpOverlapped parameter. That call should not work correctly in some circumstances according to documentation. I have spent a lot of time trying to reproduce the problem, but I was unable to! I always got all data in right place at right time. I was testing only Named Pipes though.
Would anybody know when can I expect that ReadFile() will incorrectly return and report successful completion even the data are not yet in the buffer? What would have to happen in order to reproduce the problem? Does it happen with files, pipes, sockets, consoles, or other devices? Do I have to use particular version of OS? Or particular version of reading (like register the handle to I/O completion port)? Or particular synchronization of reading and writing processes/threads?
Or when would that fail? It works for me :/
Please help!
With regards, Martin
Internally the system only supports asynchronous I/O. For synchronous I/O the system creates a temporary OVERLAPPED structure with hEvent = NULL;, issues an asynchronous I/O request passing in this temporary, and then waits for completion using GetOverlappedResult( bWait = TRUE ).
Recall that the hEvent of the temporary OVERLAPPED structure is NULL and pay attention to the Remarks section of GetOverlappedResult:
If the hEvent member of the OVERLAPPED structure is NULL, the system uses the state of the hFile handle to signal when the operation has been completed.
A file HANDLE is a waitable object that becomes unsignaled when an I/O operation begins, and signaled when an I/O operation ends.
Now consider a scenario where an asynchronous file HANDLE has a pending I/O request at the time you issue a synchronous I/O request. The system creates an OVERLAPPED structure and waits on the hFile HANDLE for completion. In the meantime the asynchronous I/O completes, thereby signaling the HANDLE causing the synchronous I/O to return prematurely without having actually completed.
Worse though is that by the time the asynchronous I/O that was initiated in response to the synchronous I/O request completes it will update the temporary OVERLAPPED structure that no longer exists. The result is memory corruption.
The full story can be found at The Old New Thing.
Seems like you are in a situation where you are deliberately calling an API in contravention of the documented best practices. In such situations all bets are off. It may work, it may not. If may work on this OS, but not on the next iteration of the OS, or the next service pack of the same OS. What happens when you port to Win64? Will it still work then?
Does calling GetLastError() (or looking at #ERR,hr in the debugger) give any value that is useful in addition to the error code?
I recommend that you call it with a valid OVERLAPPED structure, get it working and remove all doubt (and possibility of random failure). Why have possibly buggy code (and very hard to reproduce bugs) in your software when you can fix the problem easily by using a valid OVERLAPPED structure?
Why ask the question rather than fix the code to call the API as it was intended?
I suspect it always appears to work because, even though this is an asynchronous I/O, it completes very quickly. Depending on how you're testing for success, it's possible the function is incorrectly reporting that the operation completed, but it actually completes before you test the results.
The real test would be to do a read on the pipe before there's data to be read.
But really, you should just fix the code. If your architecture cannot handle asynchronous I/O, then remove the FILE_FLAG_OVERLAPPED from the creation of the named pipe.
When they say
Blockquote
If hFile is opened with FILE_FLAG_OVERLAPPED, the lpOverlapped parameter must point to a valid and unique OVERLAPPED structure, otherwise the function can incorrectly report that the read operation is complete.
they mean that there's nothing in the code preventing it working, but there's also a path through their code that can produce erroneous results. Just because you can't reproduce the problem with your particular hardware does not mean there is no problem.
If you really want to reproduce this problem, leave the code as is and go on with your life. Right about the time you've forgotten all about this problem, strange behavior will surface that will not have any obvious relations to calling ReadFile. You'll spend days pulling your hair out, and the problem will appear to come and go randomly. Eventually you'll find it and kick yourself for not following the instructions. Been there, done that, no fun!
The other way to recreate the problem is to schedule an important demo for your customer. It's sure to fail then!
If you don't want to splatter your code with OVERLAPPED structures and all of the related return value checks, Waits, Events, etc, you can write a wrapper function that takes a handle from which to read, and a timeout. Simply replace your calls to ReadFile with this handy-dandy wrapper.