2

I'm new to reverse engineering, so maybe it's an easy question but not for me). I've got .exe file which is somehow packed. When I open it with IDA, I got warning that file was packed or modified, and lots of problems, such "sp-analysis failed" and virtual addresses pointed to nowhere. IDA Unpacker plugin swamps me with warnings. I tried to analyse HEADER. Sections have wrong bounds: pointer to raw data and size of raw data seems correct, but some virtual addresses IDA cannot resolve, and in "Program Segmentation" window some sections are missed. Most of instruction in file looks like this:

___:00401000                 dd 9D3DBCCBh, 0DB7776EAh, 1F6BE17Bh, 0ADFBB803h, 4673D4B7h
___:00401000                 dd 903ADB7Ch, 0B03DACBAh, 0CA4C9D26h, 0ECFF17BBh, 0AFC80EE6h
___:00401000                 dd 0AE3EAEA3h, 5C244E1Ch, 8F68FA9Bh, 5671677Eh, 8C3CEC8Fh
___:00401000                 dd 0F56291C8h, 3D050237h, 9543FF95h, 0DA02686Ch, 6BB1A7EBh
___:00401000                 dd 32F012EAh, 99D0F3D3h, 8A8E08A5h, 1280ECB4h, 4B4ACACEh
___:00401000                 dd 0FFB892h, 5E01507Bh, 94087230h, 969DCCDBh, 8DD0AB9Bh

So what would be right approach? Should I create segments manual, and somehow say IDA to interpret it as code/data, or analyse entry point and "start" function that IDA found (with sp-analyse problem at the end)? Or it's better to try make IDA Unpacker plugin work?

Improve this question

2 Answers 2

Reset to default
2

Use a tool like PEid to try and figure out what it's packed with, then search for a tutorial of how to unpack it. If you can't find it, there are resources online to learn out to write your own unpacker (it takes a significant amount of effort).

In general, unpacking works by dumping memory after the program unpacks itself, then reconstructing an executable from the dump.

Here's a resource to get you started on unpacking: http://securityxploded.com/unpackingupx.php

UPX doesn't have any anti-debugging tricks, so it should be a good introduction.

Improve this answer
6
  • PEid says that "Nothing found [Overlay]".
    – Elventian
    May 16, 2015 at 19:30
  • When I load it with OllyDbg, it shows alert "module has entry point outside the code" and says that file is packed. How than win loader starts it, if EP in header points in wrong place?
    – Elventian
    May 16, 2015 at 19:39
  • That message doesn't mean that the header's EP is in the "wrong" place, it just means that it's outside of the header's defined code sections, which is really common in packed binaries. The packer will redirect the EP to a stub, which will dynamically unpack the code into memory, then jump to the OEP.
    – Tom Cornelius
    May 16, 2015 at 22:54
  • I'm trying now to dump my proc, but here I have problems, too... After few seconds the process becomes "system idle process" in PE tools and I dont have rights to read it's memory. Any ideas how to avoid it?
    – Elventian
    May 16, 2015 at 23:00
  • I'm not sure about the inner workings of PE tools, but it's also possible that the program unpacks itself, runs, then overwrites/destroys part of its code before it even gets to the "system idle process" state.
    – Tom Cornelius
    May 16, 2015 at 23:21
1

Well, if the packed program executes itself from a virtual environment, things are very difficult. You have to start with the call stack window of ollydbg. Try to find there in which address does it point the packer and go backwards untill you find the Original Entry Point. Then you can use the PE editors to track and remove the packer. Sounds plain sail and not really helpful, i know, but that's how it usually works... I am not very experienced, too, but i 've spent some time over manual unpacking. Wish you luck!

Improve this answer
2
  • The problem here is that my process originally started with other process. I mean, I execute proc1, which execute proc2, and target process is proc2. If I exec proc2 without proc1, it loads, but then show window with inner error (something like "you need to exec proc1 to start program"). Is there a way to debug proc2, if it's started not from ollydbg but from other process?
    – Elventian
    May 17, 2015 at 10:46
  • If what you see on the debugger screen is proc2, you have to find out from which address proc2 is callad. Track this address down to find proc1 and then the OEP thak calls proc1(OllyDump + PEiD plugin might be useful). Can't be more specific i 'm afraid...
    – Chris Tsiakoulas
    May 17, 2015 at 11:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.