Flag: Tornado!
Hurricane!
|
|
Topic created on: October 14, 2007 19:46 CDT by bodzcount  .
Hi,
I have an app which is crypted with execrypter. I have unpacked it and rebuilt OEP already. However now I have a problem rebulding IAT.
ImpRec doesn't recognize every IAT entry correctly, so i have to set them manually in imprec. However some api calls i can not set, because the dll is not listed in imprec, ie powrprof.dll. I think the problem is, that imprec only offers functions from dlls that are already loaded in the debugee. In my case, i have a breakpoint at oep where powrprof.dll is not loaded.
How can i make imprec, so that i can choose a function from powrprof.dll ?
Thanks!
I use alterative technique for recover IAT. I just remove IAT. completely. well, not completely. there is a bug in the NT PE-loader, so at lest one import must be present, just present whenever used it or not.
I add my own routine before EP, it acts like most packers: determines addresses of API-funcs via GetProcAddress and writes them directly at the place where they are called.
I use simplest heuristic algorithm: I seek CALL [mem], JMP [mem], MOV reg, [mem]/JMP|CALL reg, where mem == address that matchs some API-function.
it's quite reliable way and it works well with any packers and protectors. even if IAT is obfuscated, totally destroyed, crypted or missed - it works!
I saw many protectors removing IAT and patching callers on the fly (yes, they save address of the callers into private crypted section), so after EXE file is unpacked there is still no IAT and tools like ImpREC are fail.
if you're interesting I'll tell you more about it. Packers/Unpackers is my hobby :)
|
Hi nezumi,
Do talk about techniques that you use... we are much interested in hearing them. :-)
|
I'm glad to hear that. maybe it's worth to write an article to explain this technique in details. what do you think about it?
the only problem: my eng isn't well enough and somebody has to fix my mistakes :-) to save me of shame.
by the way, I'm going to fly to Malaysia, KL in a week or two. is here anybody from there? if so, we can meet F2F and talk about RE and many other things.
|
|
Send the article to Pedram, he will Pedramize it and post it. I would also be interested (as I am sure Ero would, not sure what Sabre uses on Vxclass to do their auto-unpacking).
|
nezumi:
Looking forward to the article. For completeness' sake, here are a few documents demonstrating this technique and some variants of it: deroko's HyperUnpackMe1 solution and his Amazing Picture Downloader solution (good work, definitely worth a read -- and if you like his stuff, check out everything written by deroko). If you look, you can find references dating back for awhile.
One downfall of this technique is that it complicates reverse engineering of the unpacked target (especially static reversing in IDA, but dynamic reversing as well), so I don't prefer this solution. See my HyperUnpackMe2 article (search for "4.4 Import Obfuscation") for an example of how I deal with relatively-addressed imports without using a loader or run-time patching.
>> I saw many protectors removing IAT and patching callers on the fly
I'm curious, which protectors are these? I'm aware of a few, but I'm interested to see your list.
|
|
armadillo is a good example aswell on patching the IAT on the fly. hence various inline tricks excists .. same for themedia
|
RolfRolles
well, "many protectors" = = "a few protectors", who counts?!
I just noticed that I saw these tricks with IAT more than once, and even more than twice :)
I can't say which packers/protectors use this mechanism, I don't remember. but...
did you see unilink by Y. Haron? it's free. ftp://ftp.styx.cabel.net/pub/UniLink/
the first of all: this is best linker ever, the second of all: Haron found out that standard IAT works very slowly, so he don't use it! yes, I kid you not! he wrote his own implementation and it works damn fast, it's the most elegant, reliable and high-speed algorithm I ever seen. source code is closed, but you can disassemble the exe-file. you'll enjoy and get a lot of fun (and know many new tricks). I promise :) I described how it works, but right now only Russian edition of the article is available.
> Looking forward to the article.
it will take some time, I'm very busy and can't promise to write it quickly, but I have put it on the top of my to-do list.
> For completeness' sake, here are a few documents
> demonstrating this technique and some variants of it:
> deroko's HyperUnpackMe1 solution and his
> Amazing Picture Downloader solution
> (good work, definitely worth a read -- and if you like his stuff,
yes! good work, indeed! and very impressed.
by the way, check this out:
* generic win32 unpacking technique
* generic Linux/BSD unpacking technique
these articles cover a lot of tricks and explain how to unpack almost any packer and some protectors. I'm interesting in UNIX ELF-packers, so if somebody has an information, I would be very glad to discuss this about.
> One downfall of this technique is that it complicates
> reverse engineering of the unpacked target
> (especially static reversing in IDA, but dynamic reversing as well),
> so I don't prefer this solution.
my point is: you don't need to restore IAT to disassemble a file, since you always can determine API-function names by its raw address, so, I prefer do disassemble raw dumps with unrestored IAT.
if you want to hack a packed program (change a couple of bytes), better use on-line patcher. it's more reliable. restoring IAT it's very risky operation and quite often unpacked program runs unstable and crashes without reasons.
jms
thanks for advice. I will do as you said.
|
Hi, interesting discussion :) I have solved my problem by injecting the needed dlls with registry kay AppInit_DLLs....
nezumi, i would be very interested in your iat-routine. I just worked on execryptor, which also does dynamic loading on iat-calls. However there is a plugin for imprec (very nice, does anybody have the source or knows the author?) that can resolv those iat entries for execryptor...
PS: execryptor uses its own GetProcAddr routine, so the plugin fails on resolving this iat entry, you have to set it manually.
regards!
|
bodzcount
ok, I try to describe how to restore IAT on the fly:
[this is short version, the long one will follow in a week or two]
1) dump the program;
2) rebuild the PE-file and clean up IAT (usually it looks like trash);
3) scan the code, seeking call ds:[address], jmp ds:[address] and save address somewhere;
4) try to resolve each address by comparing it with addresses of API-functions;
5) warring! keep in mind that some DLL can be loaded at the different bases, so you need _FULL_ dump, including _ALL_ user space;
6) create your own data-section into PE and save resolved names;
7) create your own code-section into PE and redirect EntryPoint into it;
8) write start-up procedure that reads names, loads DLL, gets funcs addresses and writes them over call ds:[address]/jmp ds:[address]
9) pass control to original EntryPoint. this is all! we have done this!
this works great, but...
1) some packers call API-function directly, like call address, keep it in mind;
2) some protectors skip a few bytes from the begin of the API-functions and emulate skipped machine commands by themselves. in this case "call address" turns into "call address+N", keep it in mind as well and seek nearest address when you're resolving names;
3) some protectors (worst ones) copy API-functions onto stack/heap, or into special section inside PE-file before run program. I don't know how to handle this. the dumped file contains API-functions that work only on the same Windows version. I see no universal way how to detect these functions and replace them with normal "call [address]". I do it manually.
AppInit_DLLs isn't the best solution. knowing the structure of PE (see the m$ specifications or if you want I can send you my articles described how to add/remove/resize any section in PE and edit imports). Adding a new DLL into import section it's easy. a piece of a cake :-)
|
[quote]I can send you my articles described how to add/remove/resize any section in PE and edit imports). [/quote]
i would be very much interested in reading them
especially tricks techniques and /or problems enlarging a dll's .code section thats relocatable versus enlarging a reloc stripped executables .code section
i have enlarged a few but those are lame (using page align versus file align spaces etc and trampolining )
i would like to see read about a real filled to the brim executable enlarged
|
Hi i used the AppInit approach just for temp. adding the dlls, so that i can rebuild iat with imprec. Imprec then adds the dlls for me to the IAT directory. I would be very interested in your articles too.
I have a strange problem now. When I remove sections (execryptor stuff) which are not used anymore, the prog doesnt run anymore :(
|
oh my god 86 pages of courier 9 size :) thanks ill take a look at your X code insertion :) a,b,c and secret Z
i was actually interested to see if the insertion could be done inplace
meaning some thing like this
address 40##### some opcode
shift everything down this address by say 0x50 bytes
add ox50 bytes of new opcodes and then simply continue
some thing like compiling and linking with a new function, an extra if() clause, an extra switch statement inside a function etc
|
anonymouse
no way! you can't move arbitrarily code down. imagine what happens if you deal with code like this:
.code
label_1:
mov eax, eax
...
mov eax, [ppp]
jmp eax
.data
ppp dd offset label_1
OK, you want to move label_1 down, but ppp is still unchanged, so jmp eax doesn't jump to mov eax,eax! it passes control to the old label_1, where is no mov eax,eax anymore!!! thus, you have to find _all_ absolute offsets and recalculate them. fixups help you if they exist, but most of the EXE files are striped. and what you're going to do with _relative_ offsets dealing with other sections? just for example:
.code1
call _some_func
...
.code2
_some_func:
retn
since, "call _some_func" uses relative address there is no fix up for it. but, you can't move .code1 down, cos this changes distance between "call _some_func" and _some_func.
well, I tell you what you have to do. move some code to somewhere. place your code and restore the original code when your code about to finish its job.
|
hi kris,
yes i understand its almost impossible to do it correctly
i was just wondering if you have some ace up your sleeve in that regard :)
anyway thanks for the article i would still need a lot of time to read it fully :)
i have no problems with trampolining or simply destroying some code and inserting a trampoline and executing the destroyed instructions in the trampoline and any other extra code (virtual alloc() creatfile() readfile() to executable memory -> and jump back to the original
thanks a lot once again
|
Note: Registration is required to post to the forums.
|
|
|
|
There are 31,328 total registered users.
|
|
![[+] expand](/imagery/files/soysauce_blueprint.gif){kind=link}