Role of Imprec

[cse_india]

usually when we want to unpack an app(packed with a simple packer) we dump it using ollydump plugin with the "rebuilt imports " unchecked , and then we rebuilt its imports using ImpRec( or some other similar tool).

1)what is ImpRec doing here. is it just rebuilding the Import table ( fixing IAT) or is it fixing the exe as a whole.
which means that if see the memory map of the dump we see no PE header and the other info(sections...) .why? just rebuilding the imports , we can see the PE header and the other stuffs.

2)now how can we rebuilt imports manually.that means cant we edit something in olly and rebuilt imports, without using ImpRec?

[WaxfordSqueers]

Quote:

[Originally Posted by cse_india;63365]1)what is ImpRec doing here. is it just rebuilding the Import table ( fixing IAT) or is it fixing the exe as a whole.

You'll get much better technical answers than mine, but I'd like to suggest you trace into your app to watch the IAT being formed. You'll see that the IAT has values (pointers) that point to addresses further into the IAT and that the initial stage is subdivided into groups of system functions like Kernel32, User32, etc. (XP will no doubt have different functions listed, but I haven't worked on XP IATs).

While the app is being loaded, it replaces the pointers and writes the actual names of the functions being pointed to. If you did that by hand, it would be a lot of work and take a lot of time. Tools like Imprec and Revirgin do that work for you, for the most part, and are able to pump out an IAT that can be pasted to your app.

It is an interactive process, however, since the tools can't always properly identify all of the functions correctly. You have to find those functions and tell Imprec about them. Sometimes that is by design, since the program writer doesn't want you to find them. They hold certain functions out of the IAT and use GetProcAddress to look up the functions as required. To answer your question, then, Imprec is saving you a lot of time and effort by finding what it can of the IAT, assembling it and giving you the option to write it as a bin file.

Unless Imprec has been changed recently, it doesn't fix up the PE header for you. If you add a section to paste the IAT, you have to tell the PE header what you did. There are tools that will add a section for you and fix up the PE header, like Lord PE. I would think you'd still have to redirect the app to your new IAT, however.

As an exercise, you might try tracing into your app till the IAT is loaded. Watch where the app is writing it to, dump it, print it and study it. Then look at whatever Imprec is able to recreate and see what might be missing. I'm sure modern apps are onto these tricks and are not going to make it that easy for you. So, you should start with a tutorial on an older app. There are some really good ones in the archives.

[disavowed]

Quote:

[Originally Posted by cse_india;63365]how can we rebuilt imports manually

Sounds like this is what you want: http://www.blackhat.com/html/bh-usa-06/train-bh-us-06-sl-advmal.html
I haven't seen the slides or video available anywhere, though.

[naides]

cse:

There are very many tutorials on manual unpacking/manual IAT in several RCE sites across the net.
immortal descendants comes to mind, ARTeam, RET. Also some long postings from long ago in this board describing to detail the process of manual reconstruction of IAT. I am hardly an expert on the subject but let me just tell you that manual IAT reconstruction is a necessary skill for unpacking: For a while now, an important aspect of packer protections is to make ImpRec algorithms fail.
Only alternative left is to understand the import dynamics and reconstruct the import table yourself.

[cse_india]

@disavowed

mine! what a course fee ! for 2 days

microsoft hates crackers but it seems microsoft people r teaching cracking!
he he

[Silver]

Quote:

microsoft hates crackers but it seems microsoft people r teaching cracking!

I don't think that's accurate. Fact is, the same reversing techniques are needed for anti-malware/anti-virus work as are used for cracking. It's like saying "Microsoft support cracking because they released windbg". The same argument applies for Compuware and sice...

I would think the guys who did that presentation are perfectly aware of this.

[disavowed]

Well put, Silver.

To say it another way, "cracking" is a subset of "reverse engineering". There are other legitimate aspects of "reverse engineering".

[cse_india]

hey guys
that was just pun intended. dont take seriously, nor did i.