Before spending several hours to hit a dead end, I thought I should consult the experts here. I want to have a background app in Win32 which can capture the memory of other apps and dump it to a text file, then have the background app restore the app to it's exact state.
It seems like ReadProcessMemory/WriteProcessMemory are functions that were created specifically for that. I understand new memory addresses will have to be created, but is there any reason why using WriteProcessMemory with new addresses could not do this? If you completely replace the process's memory, it should bring it back, right? Even if the app was closed and reopened using CreateProcess, you should get the exact same state when you completely rewrite the process's memory with WriteProcessMemory. Would the newly created addresses know how to point to each other, or is there any way to "make them know"?
Please shed some light on this to me. Thanks to all.
Related
I would like to ask what EwfSysprepSpecialize does exactly do.
So far, I know it seems to be an entry point within the ewfcfg.dll and must be related somehow to HORM and EWF. It does not activate the Ewf protection for any volume. Also, it does not bring the system into hibernate.
I experienced, that whenever the call Rundll32 ewfcfg.dll, EwfSysprepSpecialize was NOT executed before I activate Ewf, the system does not automatically restart. Whereas when this mysterious routine was executed before, the system automatically restarts.
Here someone gave the hint to use it, but I can't find any documentation about it.
Is there any expert who can provide me some information about this secret?
This is an old question, but one I also wanted to know the answer for so I'll leave this here.
Far as I can tell, it's primary purpose is to create the tiny type-45 partition at the end of the disk to enable EWF-RAM (as opposed to EWF-RAM-Reg). If you already have a type-45 partition, it is deleted and re-created. If you don't have enough free space, it won't do anything.
It's half of the solution for fixing EWF-related problems stemming from cloned images. The other is making sure the partition offset and disk signature registry entries are updated. In my own deployment I used a PHP CLI script and a couple disk utilities for that part.
Hope that helps!
I am using DE1 and VHDL. I want to update my mif file constantly and display it on VGA. I used one of the tutorials online to use In System memory content editor. But, once I complete the process, I see no instance is being created in spite of assigning instance id while creating a new megafunction. I looked online if any had come across such a problem, but theirs was quite different. They wanted to use smart compilation and things like this. What could be possibly wrong?
Now, my second question is, if I am able to edit via In System memory editor, is there a way I can write code to self update, so that once the value changes, it gets reflected on screen.
Thanks a lot in advance!
I have an MFC application developed with VS2003
It is working fine in XP vista etc.
But when i have executed it in windows 8, and we use it for some time,
then no window is displayed. Instead of that the a MessageBox with a message 'Out of Memory' is displayed. And the Message box is Having the caption of my application.
This issue is rarely occurred in windows 7 too.
I have tried watching the handles using tools like processexplorer and it is not increasing.
Also many forums says that it is because of increase in unclosed handles or resources.
Can any one suggest how can i find where the issue is. Or any one provide possible reason for this.
I cant setup the devenv in the machine causing the issue. I am confused how to diagnose by executing a test build in that.
Please provide your findings.
Thanks in advance.
You clearly have a memory leak somewhere. It's hard to be any more specific without seeing the code.
A debugger is really the best way to solve this problem. If you can reproduce the problem on your development machine, that would be the easiest case. If not, you can attach a debugger to the running process on another machine, either locally or remotely.
The MFC libraries also support some basic memory leak detection, turned on by default for Debug builds and controllable for other builds using the AfxEnableMemoryTracking function. You can use this feature to obtain information about which blocks of memory were allocated but not properly deallocated (i.e. were leaked).
Like you mentioned, Process Explorer is another good way to track down resource leaks. Are you sure that the handle counts are remaining constant rather than trending upwards over time? If the values in the columns are never changing like the question suggests, then you are surely doing something wrong. Your application has to be creating objects in order to do its job. The point is to make sure that it disposes of them when it is finished.
If you can't reproduce the problem with the running application and have only the source code available, you'll need to go through the code and make sure that every use of new has a corresponding use of delete (and that new[] matches up with delete[]). And in general in C++, you should avoid explicit dynamic memory allocation wherever possible. Instead, use the container classes that are provided either by MFC or the standard library. For example, don't allocate arrays manually, use std::vector to do it for you. These container classes ensure that the memory is automatically deallocated in the destructor when the object goes out of scope.
I have an application, which displays me some data. I need to attach to this app's process, find the data I need in memory (one single number, actually), and save it somewhere. This application doesn't seem to use standard windows controls, so things aren't going to be as simple as reading controls data using AutoIt or something similar.
Currently I'm a self-learner database guy and have quite shallow knowledge about windows apps debugging. Not even sure if I asked my question correctly enough.
So, can you give me some starter guidelines about, say, what should I read first, and general directions I should work on?
Thanks.
To read memory of other application you need to open the process with respect of OpenProcess with at least PROCESS_VM_READ access rights and then use ReadProcessMemory to read any memory address from the process. If you are an administrator or have debug privilege you will be able to open any process with maximal access rights, you need only to enable SeDebugPrivilege before (see for example http://support.microsoft.com/kb/131065).
If you don't know a much about the memory of the destination process you can just enumerate the memory blocks with respect of VirtualQueryEx (see How does one use VirtualAllocEx do make room for a code cave? as an example where I examine the program code. The program data you can examine in the same way).
The most practical problem which I see is that you ask your question in too general way. If you explain more what kind of the data you are looking for I could probably suggest you a better way. For example if you could see the data somewhere you could examine the corresponding windows and controls with respect of Spy++ (a part of Visual Studio Tools). The most important are the class of windows (or controls) and the messages which will be send at the moment when the most interesting window are displayed. You can also use Process Monitor to trace all file and registry access at the time when the windows with the interesting information will be displayed. At least at the beginning you should examine the memory of the process with ReadProcessMemory at the moment when the data which you are looking for are displayed on the window.
If you will have no success in your investigations I'd recommend you to insert in your question more information.
My primary advice is: try to find any other method of integration than this. Even if you succeed, you'll be hostage to any kinds of changes in the target process, and possibly in the Windows O/S. What you are describing is behaviour most virus scanners should flag and hinder: if not now, then in the future.
That said, you can take a look at DLL injection. However, it sounds as if you're going to have to debug the heck out of the target process at the disassembly level: otherwise, how are you going to know what memory address to read?
I used to know the windows debugging API but it's long lost memory. How about using ollydbg:
http://www.ollydbg.de/
And controlling that with both ollydbg script and autoit?
Sounds interesting... but very difficult. Since you say this is a 'one-off', what about something like this instead?
Take a screenshot of this application.
Run the screenshot through an OCR program
If you are able to read the text you are looking for in a predictable way, you're halfway there!
So now if you can read a OCR'd screenshot of your application, it is a simple matter of writing a program that does the following:
Scripts the steps to get the data on the screen
Creates a screenshot of the data in question
Runs it through an OCR program like Microsoft Office Document Imaging
Extracts the relevant text and does 'whatever' with it.
I have done something like this before with pretty good results, but I would say it is a fragile solution. If the application changes, it stops working. If the OCR can't read the text, it stops working. If the OCR reads the wrong text, it might do worse things than stop working...
As the other posters have said, reaching into memory and pulling out data is a pretty advanced topic... kudos to you if you can figure out a way to do that!
I know this may not be a popular answer, due to the nature of what this software is used for, but programs like CheatEngine and ArtMoney allow you to search through all the memory reserved by a process for a given value, then refine the results till you find the address of the value you're looking for.
I learned this initially while trying to learn how to better protect my games after coming across a trainer for one of them, but have found the technique occasionally useful when debugging.
Here is an example of the technique described above in use: https://www.youtube.com/watch?v=Nv04gYx2jMw&t=265
I am monitoring my application using Activity Monitor and whenever NSOpenPanel is called the application appears as having 9 threads and stays like that until the application is closed.
Is there a way to release those threads?, Or am I simply misunderstanding what the threads number means?, surely it isn't a good thing to have them open for no reason.
Any help would be appreciated
It looks like the threads are created for tasks such as detecting drives being mounted, so that NSOpenPanel can add them to its sidebar. It looks like a bunch of threads get created when the panel is open, and several of them are destroyed afterwards, but a few do still hang around. The threads aren't doing any work though, they're just blocked waiting for various events to happen. So, they may take up a bit of memory, but they shouldn't affect performance or anything like that. There isn't any way for you to get rid of them in your program though.