Results 1 to 9 of 9

Thread: packed dll file dropped by virus

  1. #1

    packed dll file dropped by virus


    the password to this zip file is


    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).
    Attached Files Attached Files

  2. #2
    |< x != '+' BanMe's Avatar
    Join Date
    Oct 2008
    Farmington NH
    Blog Entries
    please put pass under more visable spotting..My eyes blur sometimes o0..

    and many 'greetings'
    Last edited by BanMe; March 13th, 2011 at 18:37.
    No hate for the lost children;
    more love for the paths we walk,
    'words' shatter the truth we seek.
    from the heart and mind of Me
    me, to you.. down and across

    No more words from me, to you...
    Hate and love shatter the heart and Mind of Me.
    For the Lost Children;For the paths we walk; the real truth we seek!

  3. #3

    More Fun


    password is

    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

    Thats 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 its 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 :-)
    Attached Files Attached Files

  4. #4
    ok, so I noticed that PEid still said it was UPX so I ran the unpack again and it didnt 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

  5. #5
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Blog Entries
    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.


  6. #6
    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. i'd suggest you to try to unpack UPX->AsPack--->Yoda Protector->old Armadillo/AsProtect?
    read & unpack some these old, useful tutorial:

    ...and you'll have all you need to do this work fine.
    I want to know God's thoughts ...the rest are details.
    (A. Einstein)
    ..."a shellcode is a command you do at the linux shell"...

  7. #7
    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.

  8. #8
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Blog Entries
    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.


    when the PE file is loaded into memory, the PE loader will look at the IMAGE_THUNK_DATAs and IMAGE_IMPORT_BY_NAMEs and determine the addresses of the import functions. Then it replaces the IMAGE_THUNK_DATAs in the array pointed to by FirstThunk with the real addresses of the functions
    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"

    And you might consider trying Ollybone

  9. #9
    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.

Similar Threads

  1. a packed exe file, can't be loaded normally
    By kcynice in forum Malware Analysis and Unpacking Forum
    Replies: 9
    Last Post: July 15th, 2008, 20:56
  2. Very suspicious packed file
    By LLXX in forum Malware Analysis and Unpacking Forum
    Replies: 13
    Last Post: August 26th, 2007, 10:41
  3. how to identify if a file is packed more than once?
    By yuriprime in forum Malware Analysis and Unpacking Forum
    Replies: 1
    Last Post: April 3rd, 2005, 10:47
  4. awesome packed file
    By ON'error in forum Malware Analysis and Unpacking Forum
    Replies: 7
    Last Post: December 31st, 2001, 07:46
  5. working on a packed file
    By NikDH in forum Malware Analysis and Unpacking Forum
    Replies: 2
    Last Post: December 3rd, 2000, 18:37


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts