I'm trying to write a utility that allows me to read the memory from a process that is currently running in windows. I have used CreateToolhelp32Snapshot to build a current PID list for all programs running on the computer and I open a handle via OpenProcess with the vm_read flags without any issues. The roadblock I am running into is the readprocessmemory function of the windows API fails to read anything if the base address given is not currently readable. That being said what method can I use to determine the readable sections of a process.
My only idea on the matter is that I could iterate over the readprocessmemory function starting at the midway point of (size of process in memory)/2 and continue until I find the specific location that will allow me to read but I believe this would be terribly inefficient for large processes (o(n/2)), and even if it is the only user-mode option how would I even find the total size of the process in memory?
If this question is not meant for stackoverflow let me know and I will close it, please do not down-vote me I have been attempting to solve my problem myself for several hours now.
You can call VirtualQueryEx for each range of pages in the address space to find out if the address is in use. If the other process is not suspended then there will obviously be a chance that a pages status changes between your query and read operations.
Related
As the question states. I am certain that it is possible, but I can't find information on the subject.
I'm doing this as an experiment right now, the idea is basically to do the following scenario:
boot up linux (just because I don't like windows)
do some random stuff
dump stack and heap memory to 1 or 2 files
do some other random stuff
load dump(s) back into memory
The effect I am trying to achieve is basically hibernate a system state, but keep the system running, then wake the previous state. Not sure where I would be able to use this, but it sounds like geeky fun.
EDIT: I thought searching for sysctl hibernate sources would help, but I can't even seem to find those.
Update:
So far I have found the following information:
https://www.kernel.org/doc/html/latest/power/swsusp.html
https://help.ubuntu.com/community/PowerManagement/Hibernate
https://alioth-archive.debian.org/git/collab-maint/hibernate.git.tar.xz
Continuing the search...
I think this is where I need to dig:
https://github.com/torvalds/linux/search?q=swsusp
Also, as #Useless stated in the comments, here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/power/hibernate.c?h=v5.14-rc6
EDIT: I thought searching for sysctl hibernate sources would help, but I can't even seem to find those
It'll need to be done in the kernel, since there's a load of kernel & driver state, and it needs access to all running processes.
You can start from power/hibernate.c.
If you just skip the call to swsusp_arch_suspend() increate_image(), you should be most of the way to creating the image and then immediately resuming.
You just need to figure out how to:
keep the hibernation state around that presumably now gets destroyed on resumption
run the restore/thaw half of the code later, when you're not already suspended
I am writing anti cheat software for a video game. Using CreateToolhelp32Snapshot I can get a list of open processes. From there I would like to find the address of each process and read through its .exe file. While this works for most processes, protected processes deny access to methods such as OpenProcess or GetModuleFileNameEx. Assuming my application is being run as administrator, is there a work around to finding protected processes addresses?
Cheat Engine is not a Protected Process and neither are 99.9% of cheats. You can check the certificate for the exe in Process Hacker and you will see it only has Code Signing and no Protected Process designation.
If you cannot access a cheat's memory it's because they're protecting it with a kernel driver. You must also be running in kernel if you want to touch the process. If they have somehow created a PP then you need to be in kernel.
There are many usermode methods they can use to protect themselves as well, they can simply hook OpenProcess() in every running process including yours and return 0 when you're trying to open their process.
You would need to get a copy of the cheat and reverse engineer it to figure out how it's protecting itself, then you can start removing or bypassing these protections.
I have a C++ DLL that is used for authentication that gets loaded by a Windows service for every login.
In that DLL I use the Windows ADSI function ADsOpenObject() to get a user object from Active Directory.
HRESULT hr = ADsOpenObject(L"LDAP://rootDSE",
L"username",
L"password",
m_dwADSFlags,
IID_IDirectorySearch,
(void**)&m_DSSearch);
Generally this works since years. But currently I get the error code
-2147024882 (0x8007000E)
which is OUT_OF_MEMORY. When I restart the service that is using my DLL then it runs fine for weeks but then the errors start occuring.
Now I can't find what is out of memory. The task scheduler looks fine and free memory is plenty.
What can I do to fix that?
which is OUT_OF_MEMORY.
It is E_OUTOFMEMORY, a COM error code. The description isn't very helpful, this error code tends to be returned for any "out of resources" errors by Microsoft code, not just memory. Could by an internal limit being reached, could be a winapi call that fails.
And it is not necessarily limited to the direct software involved. A mishaving device driver that leaks kernel pool memory can be the indirect source of the mishap for example.
You'll be lucky if you can find something back in the Application event log, look both in the machine that reports the error as well as the domain server. Task Manager might give a clue, add the Handles, GDI Objects, USER Object, Commit size, Page pool and NP Pool columns. Pretty hard to give specific advice beyond this. It is no doubt a leak, quacks loudly like one when you have to restart a machine periodically to recover. Good luck hunting it down.
Are you calling Release on m_DSSearch? Also if you are searching you need to call CloseSearchHandle or AbandonSearch. If you are not doing either of those, you could be slowly leaking memory.
Your process could fragment the heap to a point so that ADsOpenObject can't find a consecutive piece of memory that is large enough.
You can use VMMap to profile your memory usage:
http://technet.microsoft.com/en-us/sysinternals/dd535533
You could try enabling low fragmentation heap:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366750(v=vs.85).aspx
If it is now starting to appear and it wasn't earlier, I would suppose one of two possibilities: it has to do with the time (more specifically the year, a milleniumbug of some kind). Another option would be a problem with 32/64 bit architecture.
Now mind that I don't program C++. But I do know a bit about MS errors (I have worked on a MS helpdesk...)
Lets take an example here which is known everywhere in the IT world:
We have a game, for example solitaire, and someone makes and releases a trainer for it that your moves are always '0'.
How do I programatically determine which adresses and what values that "hack" changes?
What way would be the best, if this is possible?
From within the game [injecting/loading my own dll?]
By intercepting traffic between the hack and target process with my own process?
I ask this question because of 2 things:
Protect an application from being "hacked" (at least by the script kiddies)
Reverse engineer a trainer (so you don't have to reinvent the wheel / avoid NIH syndrome)
You can't. Some broken attempts may be setting two addresses and then comparing them (they will find the other address though). Or they can simply remove your compare call.
They can alter any protection function that you use to "programatically determine" to always return false results. They can do anything to your executable, so there is no way.
Unless you hook the kernel functions that open your process to modify the memory. But that is also breakable and if I am not wrong you need to get your "protection kernel driver" digitally signed now.
There is another way in which you load a DLL in every running and newly spawned processes (which will probably alert antiviruses about your program being a virus), with that DLL you hook OpenProcess (and if there is another alternative to it, that too) functions in each process and check if its targeted at your program, and prevent it if so. Search about function hooking. I believe there was something called "MS Detour" or something for it.
And still, the game will not even be close to safe.
To sum up, no way is good to protect your game locally. If you are storing scores or something you should create a server program and client should report every move to server.
Even then, they can create a bot to automatically respond to server. Then the best you can do is somehow verify it is a human that is playing. (maybe captcha or comparing the solving speed with human avarage?)
Specs: Windows 7 x64, Visual C++
Objective: I'm trying to get the remote PEB from a sample program (calc.exe e.g.). I've found the proc ID and I've opened a handle to the process with all the good rights. I've now moved on to writing a class to retrieve the location of the PEB from the process using PROCESS_BASIC_INFORMATION.
Problem: I've found several posts elsewhere that seem to indicate that the NtQueryInformationProcess turned to shit at MS. One post suggests a method of dynamic-runtime-linking NtQueryInformationProcess out of ntdll.dll. However, I think this would be unstable in the long-run (MS could remove NtQueryInformationProcess tomorrow) without extensive error handling.
This idea is realized later in this thread, and it is then suggested by Mike2343 that one should "use other methods."
Questions: What would be another method to locate the PEB of a remote process that doesn't involve NtQueryInformationProcess?
Thanks to anyone who spends any time looking at this.
Method I ended up using:
I stole pretty much all of this code and fixed it up for 64-bit. I spent a ton of time wrapping my head around various documents related to all of the different headers and structs. I also ran into an issue regarding the PE32+ format, where jcopenha was kind enough to enlighten me on a few problems I might be facing. After accounting for these problems I had a functioning program that is capable of obtaining a list of all the DLL's and their respective functions loaded in by an executable along with their relative addresses.
In retrospect, I don't think I had a good handle on what I was attempting to do. I think that I thought I was going to read in a process out of memory and find the PEB related structs or something (Later I found out that image headers and the like account for the information in the PEB). Albeit that may be possible, but what I have now is an offline example that reads in exe files and works for me.