Results 1 to 10 of 10

Thread: Strange problem after unpacking

  1. #1
    tazmanian
    Guest

    Unhappy Strange problem after unpacking

    I unpacked an exe file (I posted about it a month ago), and it is a new packer...

    So here cames the problem...

    Here what I did:

    1) Run the packed program and dump it using LordPE with no pe fix from lordPe
    2) fixed the VSize and Rsize and bla bla in each section
    3) Run ImportREC.exe to get the imports and fix the dump file

    But now, when i run the unpacked file, it crashes...i dont know why :\
    All that i got is the address that it crashes...

    Here is the piece of code:
    quartzo4:004286F2 call ds:GetCommandLineA ; as we can see, it is right after OEP
    quartzo4:004286F8 mov ds:dword_460168, eax
    quartzo4:004286FD call ___crtGetEnvironmentStringsA
    quartzo4:00428702 mov ds:dword_45EA18, eax
    quartzo4:00428707 call __setargv
    quartzo4:0042870C call __setenvp
    quartzo4:00428711 call __cinit ; This is the call that crashes!!

    Folowing the call we see:

    quartzo4:0043D0FA lea eax, [esi+1Ch]
    quartzo4:0043D0FD push eax ; lpCriticalSection
    quartzo4:0043D0FE mov [ebp+var_4], edi
    quartzo4:0043D101 call ds:EnterCriticalSection ; crashes here!!!

    Do you have any idea!?

    Thank you very much!
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  2. #2
    tgodd
    Guest
    quartzo4:0043D0FA lea eax, [esi+1Ch]
    quartzo4:0043D0FD push eax ; lpCriticalSection
    quartzo4:0043D0FE mov [ebp+var_4], edi
    quartzo4:0043D101 call ds:EnterCriticalSection ; crashes here!!!


    Break at 43d0fd, and post the value of eax.

    regards,

    tgodd
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  3. #3
    tazmanian
    Guest
    This is the value for eax, i got it using Ollydbg

    Hexadecimal: 0045E74C
    Signed: 4581196
    Unsigned: 4581196
    Char: \x00 E \xE7 L

    Can be the resource data the problem? i cant read it using Exescope, nut i can read it with PEditor.

    This program uses a DLL packed with the same packer, and i unpacked the dll and seems ok, no problem until now.
    Last edited by tazmanian; February 19th, 2003 at 07:45.
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  4. #4
    tgodd
    Guest
    You should check to see which section eax is pointing too.

    You are probably off on your resizing of your sections.

    regards,

    tgodd
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  5. #5
    tazmanian
    Guest
    EAX is pointing to: 0045E74C

    Witch is inside the code section...

    quartzo2:0045E74C db 4 ;
    quartzo2:0045E74D db 0 ;
    quartzo2:0045E74E db 0 ;
    quartzo2:0045E74F db 0 ;
    quartzo2:0045E750 db 3Ch ; <
    quartzo2:0045E751 db 4Fh ; O
    quartzo2:0045E752 db 6Bh ; k
    quartzo2:0045E753 db 81h ;
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  6. #6
    : Code Injector : nikolatesla20's Avatar
    Join Date
    Apr 2002
    Location
    :ether:
    Posts
    815
    Not to distrust your unpacking skills, but I've found time and time again that if a program I've unpacked is crashing when I just try to run it (or even sometimes after that, for that matter) 98% of the time it's because there's a bad import.

    The import recovery tools are not perfect and sometimes you just have to go thru some of them manually to make sure. A few to check are

    GetCommandLineA. This gets messed up a lot!
    GetVersion.
    GetProcAddress.

    All of these calls should ALWAYS be very suspicious to you and I never trust them 100% unless I walk thru them myself. To do that, just set a breakpoint ANYWHERE in the program. The packed program. It can be after you run it, for example, set a breakpoint on CreateWindowExA and then show the about box. When it breaks, F12 back into the code.

    Now you can go to the IAT table, since you now know where it is (since you managed to unpack it) and walk thru it manually. For example, if you used ImpREC it would have told you that there was a certain import call at <address>, so do a "DD <address>" to see where that call goes. Check that address you see now, in the IAT, in SI - "U <address you found now in IAT>". You can continue to walk thru code this way, without actually exectuting the code, in SI to see where all the calls eventually end up. Yes, you have to be able to read ASM, but being able to do the IAT this way is a very useful skill if you know you have a bad import but just don't know where to start looking.

    Another hint: Imports in windows EXE's are usually always in alphabetical order. If you have one hanging out of place , be very suspicious of it and trace it manually to see if it's correct.

    -nt20
    Last edited by nikolatesla20; February 19th, 2003 at 09:41.

  7. #7
    Did you dump @OEP? This EnterCriticalSection thingie
    usually pops up, when dump is done some instructions
    later, after InitializeCriticalSection is done, and flag
    is set. When you run a dumped proggy, this dumped flag
    is checked, and program assumes, that Init is done, and
    don't call it more. As result you will get an err, entering
    not initialized crit. sect.
    Neviens.

  8. #8
    tazmanian
    Guest
    Originally posted by neviens
    Did you dump @OEP? This EnterCriticalSection thingie
    usually pops up, when dump is done some instructions
    later, after InitializeCriticalSection is done, and flag
    is set. When you run a dumped proggy, this dumped flag
    is checked, and program assumes, that Init is done, and
    don't call it more. As result you will get an err, entering
    not initialized crit. sect.
    Neviens.
    And how can i fixed it?
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  9. #9
    Either run the *packed* program under control of a debugger and pause at the OEP, or (for example, if your debugger is SoftIce) cause an infinite loop at OEP. This ensures no data is changed whilst the program is dumped.

    Dumping a running program when it has proceeded past OEP is very dangerous as you can get all sorts of variables initialised that are not supposed to be in that state on startup, so the dumped program can randomly crash - as you have experienced.

  10. #10
    tazmanian
    Guest
    newbie fault

    It worked!!! thx for help you guys!!

    I was dumping without doing a jmp eip in OEP address )

    Thx a lot!
    I promise that I have read the FAQ and tried to use the Search to answer my question.

Similar Threads

  1. ELF - problem with unpacking
    By danci in forum Malware Analysis and Unpacking Forum
    Replies: 0
    Last Post: November 19th, 2010, 09:57
  2. Strange problem when hotpatching function..
    By BanMe in forum Advanced Reversing and Programming
    Replies: 6
    Last Post: July 21st, 2009, 14:46
  3. armadillo unpacking problem
    By fighter_81 in forum Malware Analysis and Unpacking Forum
    Replies: 1
    Last Post: February 3rd, 2005, 09:41
  4. Strange problem...with softice!
    By plopzz in forum Tools of Our Trade (TOT) Messageboard
    Replies: 1
    Last Post: May 3rd, 2003, 06:40
  5. problem after unpacking asprotect
    By loman in forum Malware Analysis and Unpacking Forum
    Replies: 7
    Last Post: September 11th, 2002, 21:17

Bookmarks

Posting Permissions

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