View Full Version : A - maybe - new approach to Import Section Rebuilding
Zwyzum
October 31st, 2003, 11:43
Hi everybody.
I'm a new member of this forum, though I've been reading essays on Fravia's old site for a while. I'm quite interested in unpacking techniques and in import section rebuilding especially.
Last year I built a tool who was able to almost fully reconstruct import sections packed by Asprotect (which I explicitly chose as my target). I know it's not a great deal, but I think the technique I used might be interesting to somebody. Briefly, I used a post-mortem approach together with a peculiar environment replication - that's the way I call it - technique.
I suppose somebody would like to know why I didn't release my tool: well, it required a whole lotta manual text files formatting to get it to work properly.
I'm working on a usable version now, and I'll be glad to give further details if somebody find it interesting.
Thanks
Zwyzum
dELTA
October 31st, 2003, 11:59
Yeah, sure, new ideas are always fun to hear, feel free to post more info about it here.
Manko
October 31st, 2003, 12:35
I agree! Wanna hear more!
/Manko
Quote:
[Originally Posted by dELTA]Yeah, sure, new ideas are always fun to hear, feel free to post more info about it here. |
LOUZEW
October 31st, 2003, 12:59
Welcome !
I'm waiting for these new infos and techniques ! !
Zwyzum
October 31st, 2003, 19:07
Hi there. I promised I would have given details on demand (thanks dELTA).
I hate messing with running stuff. I always preferred a more relaxed way of doing things and also I hate that time when I blissfully debugged for 10 hours in the night because damn-ICE stopped my clock.
The approach I am to show may seem unnecessarily complex, but it gives you
the chance to experiment without constraints, and I believe this to be its most pleasant advantage.
I talked about something I called environment replication. The main idea is to artificially build an environment which is theoretically identical to the one the target really lives in, and use it to the purpose. Really, this replicated environment would be identical to its original one to the extent which is needed.
For instance, when I used this approach against ASProtect in order to rebuild the import sections it had destroyed my environment was made of a few memory dumps from the running target, as follows:
* dump of what I called (import) thunks array: it's an array of pointers (well, an array of consecutive zero-separated arrays of pointers) to the thunks of code ASProtect uses for redirecting the API calls made by the target application to the true API implementations. I found this array was always located in the PE section following the code section, maybe where the original import section lay. Also, it resembles the standard IAT of a bound PE file.
* dump of the thunks of code pointed by the entries of the import thunks array. These thunks were always contained in two or three larger chunks of memory, which base addresses could be trivially identified by looking at the array entries themselves. This even allowed me to dump both the array and the thunks in a single run of my favourite debugger, thus gathering all I needed.
* dlls loaded by the target. I'm sure everybody knows how to get a list.
Once these elements are gathered, they can be loaded at their original addresses in a dummy process to obtain the replicated environment.
I think this message is long enough for any messageboard, so I'm to talk more diffusely about the structure of this dummy process next time. Please let me know what you think.
See you
Zwyzum
To Manko: I didn't know about your tool, so I'm to study it now.
dELTA
October 31st, 2003, 20:26
Sounds like an interesting method, and it will be even more interesting to hear the next part.

Tools like Revirgin also had a quite advanced semi-generic emulation of the redirect code I think, but it will still be nice to hear about the pecularities of your method, I'm sure it differs in many interesting ways, judging from what you have told already.
Bengaly
November 1st, 2003, 05:53
actually the Idea it self is not new at all.
while we Don't use it, Some AV Softwares does.
They create an isolated Enviorment Load the target and play with it, while the target thinks it's damaging the host computer, the AV still analyze it and kick it, it may fail, may succede depend on what you analyze

i guess mabye some AVs tries the same on identifying a aspx protected viruses.
Zwyzum
November 1st, 2003, 06:39
Hi.
I really appreciate your statement about AV software using this environment replication approach. As I wasn't sure it was my invention I wrote maybe in the title of this thread.
However, you say these AV tools let virii think they're running in a true environment. But as we are concerned in import table rebuilding this is unnecessary. In fact, we don't need the real target at all. I love to keep things simple: the proper stub - together with a debugger - will make the trick.
Bye
Zwyzum
Zwyzum
November 2nd, 2003, 11:57
Hi.
Here's the continuation.
After I decided to replicate the environment the target lives in and discovered
that the technique could be applied to my ASProtected target, I stumbled upon
the problem of how I should execute the import thunks. I admit my first thought
- please notice it was just a thought - was to build an x86 emulator. I still
remember that with laughter. Luckily I am the lazy type, so I didn't started to
code what could only have been a disaster.
Rather it came to me the idea to use a simple stub to simulate the real target, then let it execute the thunks. This way I would have used the x86 itself as an emulator, though it meant I had to control the execution using a debugger. However, provided you have a decent knowledge of how code execution takes place on the x86 and you - as I did - haven't sophisticated debugging needs, Win32 API set makes this task relatively easy.
The stub I needed was to accomplish the following tasks:
* to load dlls used by the target process
* to map every memory block I dumped from the target process
* to execute an import thunk in single stepping mode, so the debugger could catch exceptions and perform analysis
I think the only interesting step is the last one, for which I used the
following rough approach:
1) the debugger notifies the stub of the address to which transfer execution
2) the stub enters single stepping mode, allowing the debugger to know where to return execution after processing
3) the debugger processes debug events until eip lies inside the address space of some module
4) the debugger resolves the import at that address using a heuristic technique
5) the debugger makes the stub return at the address following the API call
Some particular cases must be considered:
* it may happen that eip never steps in the address space of a module: this
means the API call is being emulated by the protector. I decided to ignore the
problem since it is limited to a handful of simple property accessors that I
could fix by hand. I must note that the emulation of GetProcAddress made by
ASProtect is a funny exception.
* some APIs may be redirected: in this case my tool would return the entry
point of the real implementation. Just a few functions behave this way (like
the Rtl* ones in NTDLL.DLL redirected by KERNEL32.DLL), and this thing is not
depending from the protector at all. I ignored this harmless case for laziness.
* some thunk can use a countermeasure consisting in emitting a call to a
different API function before the call to the real one; ASProtect uses
GetModuleHandle to this purpose. Since my algorithm stopped at the first API
call it met, it could have been fooled. I've got two sound reasons to ignore
this case, too: the former is that it's easy to detect and fix since you see a
lot of GetModuleHandle's; the latter is that ASProtect randomizes the code in
its thunks so bad that in most cases they are plain vanilla ones. So, rather
than prepare a counter-countermeasure I preferred waiting for a case my code
could handle.
Two of these special cases can be solved using simple exact or heuristic
techniques. The latter is difficult since it requires the ability to bypass
API calls before getting to the right one. Breakpoints can be a solution.
All I wrote till now is related to the experience I made one year ago, and my
tool provided me almost complete solutions to ASProtected imports. However,
since I downloaded Manko's AsprDbgr I'm wondering if it would be still valid
now. Manko's code - besides being a bit spaghetti - seems to be some MUCH
more complex than mine.
Can anybody tell which tricks I'm unaware of?
Bye
Zwyzum
Powered by vBulletin® Version 4.2.2 Copyright © 2018 vBulletin Solutions, Inc. All rights reserved.