squidge
December 28th, 2002, 01:24
An application protected with Crypkey Stealth component, version 6.0. Unlike the old pre-6.0 versions, these seem to be protected much better than the old ones.
When the program is run, a small temporary file is created which is 10Kb in length. This is run as a side-process to the parent and gets given several parameters, such as the full path to the parent, the parent's process ID, a location in the process ID's memory, and finally a couple of file handles to play with. It attaches itself to the parent using DebugActiveProcess and screams if it can't do it (for example, if your trying to debug the parent app). Once it has succeeded it runs the app as normal, but receives all debug notification events.
Meanwhile, the target app is decompressed and placed into memory by multiple calls to WriteProcessMemory. The import table however, is not written or decompressed. After a bit of event synchronisation between the parent and it's sibling process using CreateEvent/WaitForSingleObject, it turns into uses pipes for two way communications between the two processes.
Now, after all that, it finally places the import table into it's resting home and all API calls are resolved. This table is useless if the app is dumped unless you have something like Revirgin handy, as several things get trashed on the way.
The program then calls the OEP and everything runs as normal.
Or so you think. Dump the app and rebuild the IT and it'll still crash.
That's because instead of the normal table of JMP commands for jumping to various API calls, they have all been replaced with INT 3 breakpoint (0xCC) commands. That 10Kb sibling program the parent spawned receives the breakpoint exception as it's debugging it, and then calls the API on the parents program behalf by checking the entries in the exception structures (such as the exception address).
Once the program is finally repaired to normal, it runs as if it wasn't packed in the first place.
Has anyone noticed this kind of protection used in other programs? I'm interested to find out how they managed to implement such as scheme, looking at the old (and basic) Stealth protection used in 5.7 and earlier.
Now all I need do is write an unpacker for these executables, as they take quite a while to do manually.
When the program is run, a small temporary file is created which is 10Kb in length. This is run as a side-process to the parent and gets given several parameters, such as the full path to the parent, the parent's process ID, a location in the process ID's memory, and finally a couple of file handles to play with. It attaches itself to the parent using DebugActiveProcess and screams if it can't do it (for example, if your trying to debug the parent app). Once it has succeeded it runs the app as normal, but receives all debug notification events.
Meanwhile, the target app is decompressed and placed into memory by multiple calls to WriteProcessMemory. The import table however, is not written or decompressed. After a bit of event synchronisation between the parent and it's sibling process using CreateEvent/WaitForSingleObject, it turns into uses pipes for two way communications between the two processes.
Now, after all that, it finally places the import table into it's resting home and all API calls are resolved. This table is useless if the app is dumped unless you have something like Revirgin handy, as several things get trashed on the way.
The program then calls the OEP and everything runs as normal.
Or so you think. Dump the app and rebuild the IT and it'll still crash.
That's because instead of the normal table of JMP commands for jumping to various API calls, they have all been replaced with INT 3 breakpoint (0xCC) commands. That 10Kb sibling program the parent spawned receives the breakpoint exception as it's debugging it, and then calls the API on the parents program behalf by checking the entries in the exception structures (such as the exception address).
Once the program is finally repaired to normal, it runs as if it wasn't packed in the first place.
Has anyone noticed this kind of protection used in other programs? I'm interested to find out how they managed to implement such as scheme, looking at the old (and basic) Stealth protection used in 5.7 and earlier.
Now all I need do is write an unpacker for these executables, as they take quite a while to do manually.