From aldeid
Jump to navigation Jump to search
You are here
WinUpack / UPack


WinUpack is a packer with a GUI front-end. It is designed for optimal compression rather than for security, but still uses security measures that make it harder to locate the OEP.

The command line version of this packer is called UPack.

Malware packed with WinUpack/UPack often has corrupted PE headers. This is used as an anti-debugging technique.

To unpack this packer, use breakpoints to LoadLibrary to list loaded libraries and GetProcAddress to identify functions called. The objective is to stop at the latest loaded library and the latest called function to be as close to the tail jump as possible.

Manually unpacking WinUpack


The following content explains how to unpack Lab18-05.exe from the Practical Malware Analysis book. It has been performed on a Windows XP virtual machine.

PEiD indicates that the packer is "Upack 0.39 beta -> Dwing".

As the malware has corrupted PE headers, it produces errors when loaded into OllyDbg. Though, we can still load the malware but it can't find the entry point of the unpacking stub. The best strategy is to list loaded libraries and list functions of the last loaded libraries to identify the last one. At this point, we should be close to the tail jump.


Press Ctrl+G and enter "LoadLibraryA". Then press F2 to make a breakpoint. Do the same with "LoadLibraryW". Then run the malware (F9). It enables you to list loaded libraries:

  • kernel32.dll
  • advapi32.dll
  • wininet.dll
  • advapi32.dll
  • crypt32.dll
  • msasn1.dll
  • comctl32.dll

After the last one, the program continues. We know that comctl32.dll is the last library.


Now, let's do the same operations as above but we stop when the program reaches the last library (comctl32.dll). Then, we press Ctrl+G, we enter "GetProcAddress" and then F2 to create a breakpoint. It will enable to list loaded functions. We then run the malware several times (F9) and are able to list following functions:

  • GetSystemWindowsDirectoryW
  • CreateActCtxW
  • ActiveActCtx
  • DeactivateActCtx
  • DeactivateActCtx
  • DelayLoadFailureHook
  • GetFileAttributesExA
  • InternetOpenUrlA
  • InternetOpenA

Here again, after calling InternetOpenA, the malware continues. At this point, we know that this last call is close to the OEP.

Locating the tail jump

Now, we perform the same operations as before and stop when the malware reaches the call to InternetOpenA. Step over (F8) till the return of the GetProcAddress at offset 0x7C80AE8F and step in (F7).

You should arrive at 0x408EB4.

Step over the 2 next instructions to arrive at 0x408E9E:

This is still not the tail jump. We continue and step over (F8) the loop until it jumps to 0x408EA3 or set a breakpoint (F2) on 0x408EA3 and run (F9). Once at 0x408EA3, we step over (F8) 2 times to jump to 0x408E91.

The code at 0x408E91 is as follows:

This is not the tail jump. Step over (F8) until 0x408E96 where we see a jump to 0x408EB7. Step over (F8) once more to reach 0x408EB7. At this location, there is a simple retn instruction. We step over it wiht F8.

When you step over the retn instruction, you arrive at 0x401190, which is the OEP:

Save it with Plugins > OllyDump > Dump debugged process

Resolve imports

If you load the unpacked version into IDA-Pro, you will notice that the imports are not resolved:

To identify the function call, go back to OllyDbg, double click on EAX and enter the address of the import identified in IDA-Pro. OllDbg will resolve the import:

You can then rename the missing imports in IDA-Pro using this technique.

Automatic unpacking

This section/article is being written and is therefore not complete.
Thank you for your comprehension.

This category currently contains no pages or media.