naides
February 2nd, 2007, 17:40
I need some suggestions here.
I've been dealing with an Armadillo protection and I am a little at a lost, so I am asking for help from more seasoned unpackers here, because it has me stumped.
It starts with a typical debug blocker, which is, in the surface, simple to pass: bp on writeprocmemory etc. . .
Then when I try to find the OEP of the son process, I have hit a wall:
At the lower memory addresses of the program I saw the sections CODE, DATA, BSS, suggesting this is a Delphi program, but the sections are filled with zeros, and even after the app is up and running, remained filled with zeros. uh mm, no unpacking taking place?
Also the son process, even after detached from the "father" remained operating as a debugger breaking every few seconds on WaitForDebugEvent. . .
Who are you debugging?
Then I realized that the "son" app has spawn a new process (The grandson) which is running the show. If I dump the grandson process while fully running in memory, I can see unpacked, functional code inside the CODE section. Trying to detach the grandson from the son only results in a new generation: the kid spawns a new process, declares itself the debugger of the great-grandkid and I am back to square one.
So: the debug blocker trick has matured. If the application finds itself orphan, meaning detached from the father, it becomes a father(being under Olly as a debugger does not prevent that behavior) If it finds itself under the father as a debugger, it abstains from sex, unpacks itself and runs.
This is a problem of the rooster the chicken and the egg, and I find it intriguing, and challenging.
I am asking the local unpacker gurus if they have seen this strain of Arma and some suggestions on how to solve this catch. . .
I've been dealing with an Armadillo protection and I am a little at a lost, so I am asking for help from more seasoned unpackers here, because it has me stumped.
It starts with a typical debug blocker, which is, in the surface, simple to pass: bp on writeprocmemory etc. . .
Then when I try to find the OEP of the son process, I have hit a wall:
At the lower memory addresses of the program I saw the sections CODE, DATA, BSS, suggesting this is a Delphi program, but the sections are filled with zeros, and even after the app is up and running, remained filled with zeros. uh mm, no unpacking taking place?
Also the son process, even after detached from the "father" remained operating as a debugger breaking every few seconds on WaitForDebugEvent. . .
Who are you debugging?
Then I realized that the "son" app has spawn a new process (The grandson) which is running the show. If I dump the grandson process while fully running in memory, I can see unpacked, functional code inside the CODE section. Trying to detach the grandson from the son only results in a new generation: the kid spawns a new process, declares itself the debugger of the great-grandkid and I am back to square one.
So: the debug blocker trick has matured. If the application finds itself orphan, meaning detached from the father, it becomes a father(being under Olly as a debugger does not prevent that behavior) If it finds itself under the father as a debugger, it abstains from sex, unpacks itself and runs.
This is a problem of the rooster the chicken and the egg, and I find it intriguing, and challenging.
I am asking the local unpacker gurus if they have seen this strain of Arma and some suggestions on how to solve this catch. . .
)