If you could help me with this dilemma I have. Now, I know C \ C++, I know asm, I know about dll injection, I know about virtual memory addressing, but I just can't figure out how
software like CheatEngine, and others, manage to change a variable's value in another process.
For those who don't know, 3rd party cheat engine tools can scan for values in the memory space of a program and identify the location of a variable with a given value and change it.
My question is, how do they do it?
Given an address, if I were to write C code, how could I change the value at that address belonging to another process without getting an invalid addressing error?
Thanks.
I'm fairly certain those programs are pretending to be debuggers. On Windows, I would start with DebugActiveProcess() and go from there.
Oh, and the very useful looking ReadProcessMemory() function (and WriteProcessMemory()).
On unix: ptrace()
You can't do this with Standard C or C++ - you have to use operating system specific features. So you need to tell us which OS you are interested in.
You may also be interested in Detours:
Software packaged for detouring Win32 and application APIs.
Related
Is it possible to tell Visual Studio (or any other tool even on any other major operating system) to interpret an address as a beginning of a call stack?
What I'm trying to achieve: we have a library, which uses boost's make_fcontext / jump_fcontext and stores these contexts into a container in order to suspend some calls for later processing.
My question is - is it possible to somehow debug what are these suspended calls? I imagine, that I can tell a debugger/tool something like: "Here's this address, although it's not obvious, it actually points to a call stack, 'parse' it and show it to me like a standard call stack".
No idea if it's theoretically possible, as I don't know boost::context in details, but it sounds achievable.
Has anyone tried to deal with this?
There's a few approaches I can think of, in various flavors of dissatisfying.
You could write your own debugging engine to plug into the IDE, which would allow the manual enumeration of fibers. (You probably don't want to do that.)
You can use a boost::context::fiber instead of a fcontext_t. On Windows, those can be implemented with win32 fibers, so they'll show up in the IDE automatically, with full stack/locals. (You may need to change your Boost config to get this to work, see the docs for details.)
You could look inside the fcontext_t struct, get the EIP and ESP, and copy them into your registers; at that point, the processor will kiiiind of think that it's executing as the fiber. (This is most likely NOT going to work very well.)
Personally I'd go with the second approach. fcontext_t is a bit too low-level to be using directly anyway, unless you have specific exotic needs you haven't mentioned.
I'm working on a c++ windows application project. A portion of this project requires me to read the value of a memory address used in a separate process and use this value as a "trigger" within a function. I know the value is a string, and constantly changes, but i have no idea how to read or use it. Any ideas? Any help would be wonderful.
Are you allowed to use standard IPC? If not, you're going to run into issues. Processes are not supposed to share memory space like that. In fact, if you compile with standard settings and try to read outside your application's memory space, you'll get a fatal seg-fault.
What you're going to want to do is essentially design a very rudimentary debugger, which is no small task. I would recommend starting by looking at existing debugger source code (e.g., x64dbg, or cheat engine: https://github.com/cheat-engine/cheat-engine).
What is the purpose of this project?
I am building a C++ application for Windows that I'm going to hook with a DLL (in assembly code). But I'm having problems reverse engineering the console application I made.
I want to keep the function addresses in the same place, but they keep moving in memory each time I edit and rebuild the DLL.
Is there a way to keep them in the same place? And is there a way to keep the backing storage of a variable (e.g. int) in the same spot (memory address)?
You don't need to hardcode addresses in assembly language.
You can just link with the DLL as usual.
If this doesn't work for you, post code and exact problem description.
Short answer: no. I've never heard about compiler/linker with this feature.
I have asked pretty much the same thing before, but my post got deleted for some reason.
Anyway, I'm trying to use C++ and write a program that allows me to access directly to the memory and write stuff to it. I heard I need to do something with the kernel as that is a "bridge" that connects the OS and application (I think). Is there anyway I can download some sdk for the kernel?
I've said this in my previous post (which got deleted after some time) that the reason to this is because I want to try and crash windows 7 as my professor at university asked me to. (so please don't ask me stuff like "why do you want to crash windows?" or something along those lines...)
Any help will be greatly appreciated.
If you're interesting in working with the kernel, you're likely looking for the Windows Driver Kit, found here:
http://msdn.microsoft.com/en-us/windows/hardware/gg487428
It has a variety of lower-level tools and headers to help you write drivers and other kernel-mode code.
Typical programs obviously don't have carte blanche access to memory, while drivers have more control (although I would guess they use the system's memory management as well, not entirely sure). You'll find more information in the WDK.
Write a driver, make it crash. Of course, in only very specific circumstances will this actually make Windows 7 crash (because, unlike the public opinion, it wasn't written by total idiots).
You can use the RtlSetProcessIsCritical function in order to flag that your process is critical for system operations.
If your process is terminated (for example if your application calls ExitProcess) a bluescreen will appear. In order to use this function you need to enable the SE_DEBUG_NAME privilege.
I want to create a file that only resides in memory... In looking through some documentation I saw a recommendation to use a shell extension as a virtual file. Im not sure that is a workable solution but I would like to know
Is it a good approach (or should I be using a ramdisk instead)
Where is a good place to start to read up on it
Note: This is on the Windows platform
As I understand, you want your program to create a "file", which resides only in memory and that you can pass on to another external program (say, Microsoft Word).
AFAIK this is not possible, short of a ramdrive. I'd suggest using a temporary folder. You will however have to come up with a strategy for deleting the file when it's not needed anymore.
Added: On second though, you might want to check out Reparse points. I'm not familiar with them myself, and they will only work for NTFS formatted disks, but perhaps they can provide you with what you want. It will be a lot of coding though.
You don't say on which plateform you are but I'm guessing Windows. Is mmap() available? If not, I think BerkeleyDB has been ported to Windows so you should be able to use that. Win32 API may have something akin to mmap() but I don't know it.
If you want a file that resides only in memory, use a named pipe or something, though I question your scenario - can you go up a level and describe what you want to do?