MALWARE!!!

the password to this zip file is

iblamechina

havent had much chance to look at this. I just noticed that this dll file was dropped by a virus our security team was removing from a box. Has UPX headers although It doesnt resemble other UPX packed files I have seen. This is a part of a larger mess that I am trying to find the other files for. It's possible that this is modified by another exe before use. Anyone want to take a shot at unpacking? I have to find the rest of the pieces on our server before someone deletes them (if there aren't gone already).

please put pass under more visable spotting..My eyes blur sometimes o0..


and many 'greetings'

MALWARE!!!

password is
iblamechina

OK, I finally caught the exe that I believe uses the DLL I posted above. It was upx packed and this zip file contains the unpacked file. Now I can see meaningful code in IDA but it's still not in its native format.

I see this at the entry point

UPX0:00403244 start proc near ; CODE XREF: UPX1:0074E6D3 j
UPX0:00403244 adc ebx, edi
UPX0:00403246 push ebp
UPX0:00403247 mov ebp, esp
UPX0:00403249 add esp, 0FFFFFFCCh
UPX0:0040324C not edx
UPX0:0040324E sbb ecx, edi
UPX0:00403250 neg ebx
UPX0:00403252 inc ecx
UPX0:00403253 mov edx, 0F3AE52FCh
UPX0:00403258 add esi, ebx
UPX0:0040325A inc ecx
UPX0:0040325B dec edi
UPX0:0040325C mov ebx, edx
UPX0:0040325E inc edx
UPX0:0040325F sbb edi, ecx
UPX0:00403261 sub ebx, 0F36E3321h
UPX0:00403267 not edi
UPX0:00403269 push ebx
UPX0:0040326A sbb edi, ebx
UPX0:0040326C sub edx, esi
UPX0:0040326E not ecx
UPX0:00403270 retn
UPX0:00403270 start endp ; sp-analysis failed

That’s valid assembly and would seem it's messing with the stack manually so that when 'retn' is run it will pop an address off the stack and jump there.

I fired up the debugger to investigate and immediately ran into the problem of not being able to break on this code. I know you can stop software breakpoints in your code but at the entry point? No code from the EXE should run before the break on the entry point. I know about the tls trick but IDA identifies that additional entry point automatically when it’s there. I tried the hardware breakpoint option in IDA as well just to be safe. Just be careful all, it may skip your breakpoint and just install on your system when you try and debug. Snapshot that VM :-)

ok, so I noticed that PEid still said it was UPX so I ran the unpack again and it didn’t throw any errors and produced a different binary. At least PEid now says that the type of packing on this new file is unknown. Entry point is now this. I cannot set a breakpoint here either.

UPX0:004030DE public start
UPX0:004030DE start proc near
UPX0:004030DE leave
UPX0:004030DF retn
UPX0:004030DF start endp

Hi whitey, welcome to the board.

Thanks for the file but unfortunately the imports are hard coded addresses at this point in the dump, so no one else can run it unless they've got the same combination of service pack/updates as you have.

I was able to rebuild the true upx IAT by changing the First Thunk hardcoded offsets for each import to RVA's pointing to the "hint" word offset before each import name. A fun little exercise in itself some may want to try if so inclined.

So anyway, now the file will execute, for a bit. As you say it makes a bunch of calls which pushes stuff onto the stack, with a bit of patience you can single step through it all. Then the code "unwinds" itself with an equivalent number of LEAVE/RET statements.

Finally it starts using an imports jump table, I think at
UPX0:00403A37 jmp dword_40413C

Unfortunately the jump table is already filled with hard coded offsets again, and the app crashes.

The thing is, there is no code from OEP to jump table use which resolves the internal malware imports, so I'm not sure how they got there. Presumably it happened in the unpacking code, which is no longer referenced here, or possibly this is a secondary exe and its IT was resolved/created in memory by another exe, and that's what you dumped here?

We really need a rebuilt file or the original unpacked exe if available to be able to analyze it properly.

Cheers,
Kayaker

hi withey,

may i suggest you to learn basic/average manual unpacking techniques before delving with malware?
Most malware is packed, use anti-debug/IDA/VMWare/VM/Obfuscation tricks etc. which you can learn to defeat while unpacking. You dont need to become an unpacker god, but at least be able to recognize common packers at sight/know how rebuild IAT etc.

...so i'd suggest you to try to unpack UPX->AsPack--->Yoda Protector->old Armadillo/AsProtect?
read & unpack some these old, useful tutorial:
http://www.reversing.be/search.php?query=haggar&type=all&mode=search

...and you'll have all you need to do this work fine.

Thanks to both of you. The website is very useful maximus. I have read 5 or 6 and will read all the rest of the tuts.

I can post the original exe I found if needed. I just thought people on the board would be interested in a real world crackme. I don't expect you folks to reverse malware for me at all. I "think" i have the code already but i can't prove it. I am admittedly weak with packing/unpacking. The way i usually get around that is by configuring the infected/target machine for a full memory dump. Then I use the NMI button or software to force a BSOD / full mem dump. Then I dump the unpacked and running process or dll from memory dump to file. I have some bad actual code; just don�t know how it gets into memory.

Two questions if I may


- Is it the case that this exe was modified with hard coded offsets in this way by me during upx unpacking? I hear what you say Kayaker but my understanding is that upx does not work that way. I believe it�s modified by outside process but I know I need to understand UPX fully as it is basic.

- Is it because the PE format was damaged and failed to fully load that I could not set BP on entry point? Was it crashing on loading / in loader before it even got to the actual PE entry point? (did break in on ntdll code) I ask this because I don't know of a way to execute code before the entry point other than tls.

With regards to the first question, the PE Loader converts import RVA's to hard coded offsets by default. Even if you break at the start of notepad and dump it, no one else could run it unless they have the same mix of dll versions.

From
http://win32assembly.online.fr/pe-tut6.html



For a packer or malware which sets up its own internal import table via LoadLibrary/GetProcAddress, it generally does the same thing, uses a table of hard coded addresses. That's why "rebuilding" import tables of unpacked files is done.


For the second question, I'm not sure why it didn't break on the EP. Are you talking about the dumped file that you posted? As I mentioned it was corrupted because of the hard coded upx imports and wouldn't load, when I changed them back to RVA's I could get it to load and break on the EP (using Softice).

No matter, if you've got the original unpacked exe you should be able to dump and rebuild it in a proper way following those tuts. I don't know what's mentioned in them, but you might also take a look at the popular Lena tuts.

A couple of other thoughts that come to mind for the simpler packers, you should get to know the "ESP trick"

http://securitylabs.websense.com/content/Blogs/2927.aspx

And you might consider trying Ollybone

http://www.woodmann.com/collaborative/tools/OllyBonE

ESP trick worked great with only minor additional steps but somehow I suspect you already knew that. I'm in. Thanks again. With the links you both sent me and this exe i will have my hands full for a few days.