How to determine what code created a string, in a live debugger session?

Question

I'm using IDA 7 to debug a running application that must be a child of another application, which means I can't start it from IDA (using Debugger->Run). Instead, I have to run the application normally, and then attach IDA's debugger to the application after the application is already running. But, by the time I get the debugger attached, there are some important strings that the application has already created in the memory. These strings are not something I can find by any kind of simple hex search in the static exe binary, they only seem to appear in the memory after the application is running, so I assume they are being decompressed from somewhere. So I'm trying to determine what code is responsible for creating these strings, so that I can track down where these strings come from. Each time I run the application, the strings are found at different memory addresses. Since I can't debug the program prior to the creation of these strings, I can't step forward to see these strings as they are being created, I can only see them after it's too late. Is there a way to work backwards from a string that's already been created at a variable spot in the memory, and from there, work backwards to determine what code created it?

Answer 1

I don't know IDA debugger very well, but I can tell how it can be done in GDB.

First of all, I would suggest disabling ASLR (echo 0 | sudo tee /proc/sys/kernel/randomize_va_space) to prevent address space randomization. If the string you are looking for is at the same location each time, then simply setting watchpoint at that location will do the job.

If that is not the case, the only easy way I see, to achieve your goal will be to debug your application from its start. In GDB, you can do this using set detach-on-fork off option before executing the program, which does the following:

Both processes will be held under the control of GDB. One process (child or parent, depending on the value of follow-fork-mode) is debugged as usual, while the other is held suspended.

So, if follow-fork-mode is set to parent, GDB will only execute parent process while child will be frozen until you run it in another GDB instance for example (you can also use IDA debugger to attatch to the newly created process).

I'm posting the links you may find useful while using GDB as I decribed above:

• searching for strings in GDB
• debugging forks
• similar question on stackoverflow