Showing posts with label PE. Show all posts
Showing posts with label PE. Show all posts

Tuesday, February 10, 2015

View PE header - Olly 2.01

Many times we want to view the PE header to study certain fields. Its easy enough to do this with a million PE editors out there. You could even do it programatically - I use the pefile module in Python to do it. There's almost certainly others. But the point is... that I love Olly :). How can we do it in Olly?

Well, in Olly 1.10 you could go to the PE header location in the Dump section, right click and select Special - PE header. And this would perfectly parse the PE header and display it in the Dump. Or just go to View - Memory Map, right click and select Dumo.

But Olly 2.01 doesn't have this. The option seems to have changed. I had trouble finding it but finally managed. There is no Special -> PE header menu but a 'Decode as structure' menu.  Here are steps on how to view the PE header in Olly 2.01:
  • View - Memory Map. Locate PE header for the exe. Get the address from here.
  • Go to the Dump section of Olly. Ctrl+G - enter address.
  • So you can right click on the start of the PE header (MZ)  - Decode as structure and in the Drop down box there select IMAGE_DOS_HEADER. Now you see just 1 section decoded.
  • Scroll down a bit till you come to the PE header. Right click on the PE header (anywhere...but make sure its inside the PE header, not the DOS header - Decode as structure - IMAGE_FILE_HEADER.

And so on.. use all the different IMAGE_ structures to decode the entire header. Its a bit of a pain really, and I preferred the old way :( or maybe just use another tool - just not Olly 2.01 for this. Its good for other structures though..probably, as you might have guessed.

Extracting PE files from memory

Was recently trying to debug some malware that someone gave me. The malware was extracting itself into memory and working from there. It is possible to debug the malware from memory itself but its a bit painful, since we have to debug the entire memory each time, let the memory get populated with the malicious code and then try and understand what the code is doing. This is a waste of time - and if we can avoid it, we should.

As it turns out, its possible to dump contents from memory. This is specially useful if its a PE file that's unpacked into memory. Coz.. you could dump it and reverse it separately without all that running of the original malware that unpacked it.

I always knew this was possible but for many reasons (a laziness to learn being foremost ;)) I never did it. This time, I was determined to figure out how to do it. Turns out it is fairly straightforward. All credit for me learning this goes to this blog - http://www.joestewart.org/morphine-dll/

That blog should be self explanatory really, but here were my steps.
  • Load process in Olly and debug it as usual.
  • Once the process has loaded in memory, locate it in the Dump section of Olly.
  • Right click inside the dump. Backup - Save data to file to an EXE file on disk.
  • Launch a PE Editor (I use LordPE). Locate the last section. Add the RawSize and RawOffset. Record the number.
  • Open the hex editor and go to this number (offset) inside. Delete all content after this number. Usually this is all zeros.
    Now go to the start of the file. Delete all content inside the file upto the start of the header (4D 5A). Save the file.
  • Open the file in Olly...and there you go.. a normal EXE file.

I tried some plugins like OllyDumpEx but they did not work for me. They probably are fine - just that I mostly made a mistake while using it. I will try some nice plugins soon and update this post when I am done.

Hope this post helps someone easily unpack malware from memory manually. Its fairly easy and you do not need a plugin to do this :)

Sunday, November 30, 2014

Fireeye - Flare-On Challenge 3

Number 3 was another EXE file. Apart from CFF Explorer, I also load these EXEs into PEid, RDG Packer detector and Protection ID... just to get a feel of how hard it's going to be. These tools are great...but again they only compare against a signature database... so they will miss stuff too. Anyway this time...nothing was detected, all clear.

You can reverse stuff statically...in IDA or you can run it in a debugger like OllyDbg. I always prefer running things... its much quicker. And then use IDA side by side to understand the flow of code..so I can set breakpoints in the right places. Always make sure though...that you run all this stuff inside a virtual machine :D and turn outbound connections off unless you're absolutely sure of what you're doing.

So anyway I loaded this up in OllyDbg and ran it...and it crashed with an error message. Time to Step In (F7). The function exits inside 401000. Something inside this.

401000 copies a lot of code into memory. Nothing looks like ASCII. The start address (18FD47) of this "encrypted" block is then called. This means that an entire function was moved at run-time into memory and then called. Code between 18FD57 and 18FD61 XORs memory with hex 66 (f) and obtains an ASCII string in memory "and so it begins".

So already this points to...the flag eventually being in memory. The start of another encrypted block is at 18FD78. The word "nopasaurus" is compared for some reason :) and some more math results in "get ready to get no'ped..."

Slowly going through all code gives the 3rd flag ... in one of the registers (EAX I think).

The Email address is: such.5h311010101@flare-on.com

Trying to run further causes a crash at 18FF47. That's why you have to Step into and not F9 :).

It's easier to just find out where the crash happened and set a break point just before that... but I just did this slowly to show how to debug things manually.