Malware Analysis Professional: Analyzing Packers and Manual Unpacking

Malware Analysis
Professional
Analyzing Packers and

Manual Unpacking
S e c t i o n 0 2 | M o d u l e 1 4
© Caendra Inc. 2020
All Rights Reserved
Table of Contents
MODULE 14 | ANALYZING PACKERS AND MANUAL UNPACKING
14.1 Introduction
14.2 Well-known Entry Points
14.3 Methods to Reach the OEP
14.4 Packers and Tools Used
14.5 Conclusion
MAPv1: Section 02, Module 14 - Caendra Inc. © 2020 | p.2

Getting Started
Tools:
• Olly Debugger v1.10
Target:
• Packed_Samples.rar
www.ollydbg.de MAPv1: Section 02, Module 14 - Caendra Inc. © 2020 | p.3

14.1
Introduction

14.1 Introduction
Like studying anti-reversing tricks, manual unpacking is

considered another important part of the art of reverse
engineering.
In order to understand what this is, try and think about

music and all its different types: rock, metal, classic,
dubstep…, every music type is special and can be
considered a different chapter in the history of music
evolution.
14.1 Introduction
In a similar way, manual unpacking can be considered an

entire section of reverse engineering by itself.
The concept refers to the process of studying in detail

executable packers with the ultimate goal being the
successful retrieval of the original executable code and, in
most cases, working executable code that runs
independently from the layers of code that were added by
the packer.
14.1 Introduction
An executable packer (a packer for executable modules) is

a piece of code or an application that compresses and
encrypts another application in order to protect its code
from reverse engineering.
In the past, packers were mostly used for compression,

simply to make the executables smaller.

14.1 Introduction
However, these days, packers (especially the commercial

ones) are mostly used for protection purposes and not for
saving space.
Most sophisticated packers incorporate a vast variety of

anti-reversing tricks along with obfuscation mechanisms
and cryptographic algorithms. This makes the analysis of
the protected code as difficult as possible.
14.1 Introduction
In this module, we’ll go through some simple packers and

demonstrate how to unpack the original executable. We will
be doing this by demonstrating some generic
methodologies that can be used to study other packers that
you might encounter in the future.
Fortunately, there are loads of resources that can be found

online regarding this subject in case you want to dig deeper
into manual unpacking with a bigger variety of packers.
14.1 Introduction
Since it wouldn’t make much sense explaining the

unpacking process statically, we are only writing down the
necessary theory which we are going to use in the
associated demonstration videos.
NOTE: Your Anti-Virus may trigger a false alarm on the

packers used in the practical part of this module.

14.1 Introduction
A few words before starting…

Even though we already mentioned this in the introduction, we
think it is very important to state this again. What you should
really pay attention to are the concepts of the methodologies we
will be using, not necessarily the packers themselves. These
packers are only used as examples, but there are many different
types of them in the wild.
However, if you focus on the methodologies and concepts then

you might find your way out of different scenarios later, which, to
us, represents the ultimate goal of learning: inspiration.
14.2
Well-Known Entry
Points

14.2 Well-Known Entry Points
As we said, our goal is to retrieve a working executable out

of the protected application which is now hidden under the
layers of code that were added by the packer.
In order to achieve this, we need first to find the Original

EntryPoint (OEP) for the application. This is the first
instruction of user code inside the application that would be
normally executed once the process has been created by
Windows Loader.
In this scenario it would help a lot to be able to recognize

common entry points (EPs) generated by well-known
compilers like MS Visual C++ Studio, Borland C++ Builder,
Visual Basic-based applications, etc.
If you can recognize these entry points, we can search for

specific byte patterns in memory and, even further,
monitor the calls to specific APIs that we know should
always be called at the beginning of code execution
generated from a specific compiler.
We wouldn’t want to let you remain curious about this, so

here are some examples of EPs generated by well-known
compilers.

Microsoft Visual C++ 6.0

PUSH EBP
MOV EBP, ESP
PUSH -1
PUSH 005C7D70
PUSH 005035E0 ; SE handler installation
MOV EAX, DWORD PTR FS:[0]
PUSH EAX
MOV DWORD PTR FS:[0], ESP
SUB ESP, 58h
PUSH EBX
PUSH ESI
PUSH EDI
MOV DWORD PTR SS:[EBP-18], ESP
CALL DWORD PTR DS:[&KERNEL32.GetVersion] ; kernel32.GetVersion  first API call

Microsoft Visual C++ 7.x

004023FD 6A 74 PUSH 74
004023FF 68 A03A4000 PUSH 00403AA0
00402404 E8 F3010000 CALL 004025FC
00402409 33DB XOR EBX, EBX
0040240B 895D E0 MOV DWORD PTR SS:[EBP-20], EBX
0040240E 53 PUSH EBX ; /pModule => NULL
0040240F 8B3D 3C304000 MOV EDI, DWORD PTR
DS:[&KERNEL32.GetModuleHandleA] ; |kernel32.GetModuleHandleA
00402415 FFD7 CALL EDI ; \GetModuleHandleA  first API call
Microsoft Visual C++ 8.0-9.0

0047DF0E E8 F7730000 CALL burnings.0048530A  in the called
function first API to be called is GetSystemTimeAsFileTime
0047DF13 E9 17FEFFFF JMP burnings.0047DD2F then this jump
takes us to something looking like the following…
0047DD2F 6A 60 PUSH 60
0047DD31 68 787B4E00 PUSH 004E7B78
0047DD36 E8 B9400000 CALL 00481DF4
0047DD3B 8365 FC 00 AND DWORD PTR SS:[EBP-4], 0
0047DD3F 8D45 90 LEA EAX, DWORD PTR SS:[EBP-70]
0047DD42 50 PUSH EAX ; /pStartupinfo
0047DD43 FF15 78824B00 CALL DWORD PTR
DS:[&KERNEL32.GetStartupInfoW] ; \GetStartupInfoW  second API call
Borland C++ Builder (any recent version)
0040154C EB 10 JMP SHORT a.0040155E
0040154E 66 DB 66 ; CHAR 'f'
0040154F 62 DB 62 ; CHAR 'b'
00401550 3A DB 3A ; CHAR ':'
00401551 43 DB 43 ; CHAR 'C'
00401552 2B DB 2B ; CHAR '+'
00401553 2B DB 2B ; CHAR '+'
00401554 48 DB 48 ; CHAR 'H'
00401555 4F DB 4F ; CHAR 'O'
00401556 4F DB 4F ; CHAR 'O'
00401557 4B DB 4B ; CHAR 'K'
00401558 90 NOP
00401559 E9 DB E9
0040155A AC404F00 DD OFFSET CPPdebugHook
0040155E A1 9F404F00 MOV EAX, DWORD PTR DS:[4F409F]
00401563 C1E0 02 SHL EAX, 2
00401566 A3 A3404F00 MOV DWORD PTR DS:[4F40A3], EAX
0040156B 52 PUSH EDX
0040156C 6A 00 PUSH 0 ; /pModule = NULL
0040156E E8 BD110F00 CALL [JMP.&KERNEL32.GetModuleHandleA] ; \GetModuleHandleA  το πρώτο API που καλείται.

Dev-C++ 4.9.9.2
00401220 55 PUSH EBP
00401221 89E5 MOV EBP, ESP
00401223 83EC 08 SUB ESP, 8
00401226 C70424 01000000 MOV DWORD PTR SS:[ESP], 1
0040122D FF15 D0504000 CALL DWORD PTR
DS:[&msvcrt.__set_app]; msvcrt.__set_app_type  first API to be
called
00401233 E8 C8FEFFFF CALL 00401100
Borland Delphi 6.0-7.0

0046488C 55 PUSH EBP
0046488D 8BEC MOV EBP, ESP
0046488F 83C4 F0 ADD ESP, -10
00464892 B8 0C474600 MOV EAX, 0046470C
00464897 E8 341DFAFF CALL 004065D0  in this
function the first API calles is GetModuleHandleA

Microsoft Visual Basic 5.0-6.0

00401258 FF25 74104000 JMP DWORD PTR
DS:[&MSVBVM60.#100>] ; MSVBVM60.ThunRTMain
0040125E 00 DB 00
0040125F 00 DB 00
00401260 68 289F4C00 PUSH 004C9F28 entry point
00401265 E8 EEFFFFFF CALL [ JMP.&MSVBVM60.#100] first
call to MSVBVM60.ThunRTMain

MASM32/TASM32
00401000 6A 00 PUSH 0
00401002 E8 D7020000 CALL
[JMP.&KERNEL32.GetModuleHandleA] ; \GetModuleHandleA  first
API to be called
00401007 A3 6C304000 MOV DWORD PTR DS:[40306C], EAX
0040100C E8 C7020000 CALL
[JMP.&KERNEL32.GetCommandLineA] ; GetCommandLineA

14.3
Methods to Reach
the OEP

Even if it’s true that each packer uses different methods to

reach the OEP, it’s also true that there are some generic
methods that we can use in order to find the OEP quickly
and save time.
Of course, as with everything in Reverse Engineering, you

should only use these methods in conjunction with some
critical thinking by trying to understand what really happens
in each case.
As you already understand, there is no guide-dog in the

world of reverse engineering. You always need to use your
skills and instincts to find your way out. You might have a
stick as the only tool in your hand but remember that even
if the stick is all you have, you’re the one guiding it.

1. Investigate near the EP for instructions such as:

• Jxx reg (for example ‘jmp eax’)
• push VA
ret
• Call reg (for example ‘call ebx’)
• Jxx/call dword ptr ds:[reg] (for example: je/call dword
ptr ds:[ecx])
• jmp/call dword ptr ds:[mem] (for example: jmp/call
dword ptr ds: [00450000])
Some packers, especially simple ones still used for packing

malicious code, have the instruction that transfers
execution to the OEP very near their EP and it might be
possible to locate that instruction quickly by visual
inspection.

2. Analyzing long loops – Find the way out.

Sometimes it makes sense that if we manage to keep
control of the execution and break after long loops, it is
quite possible that we’re very close to the OEP. In other
words, since loops are usually used for code decryption and
resolving API addresses used by the packed application, if
we manage to stop right after those, we have a good
chance to find the OEP.

3. The ESP trick

This trick has been widely used and it is one of the best of its
kind. It is actually very helpful for packers that use the following
design pattern:
PUSHAD
….........
…......... ← rest of packer's stub (decryption, IAT resolving, etc.)
….........
POPAD
4. jump to OEP
This trick relies on the fact that some packers, at the
beginning or at some point during their execution, will save
all the general purpose registers before doing their own
necessary operations. Then, they will restore them shortly
before reaching the OEP. So, by setting a HW breakpoint on
access, where the ESP points after the PUSHAD instruction,
we can manage to break in when the POPAD instruction is
executed since that memory area will be accessed.
5. Follow SEH
Many packers use exceptions as anti-reversing tricks in
order to redirect the execution where they want, without
using obvious methods like a jump or a call instruction. So,
by monitoring the exception handlers and where the
execution is about to be transferred, we can create another
path towards the OEP.

6. Exception Counting + BP Memory on access

Some packers use more than one exception type to trick the
analyst and his tools. By counting how many exceptions occur
before the application actually runs, we can manage to get very
close to the OEP and eventually locate it.
If, for example, we know that after four exceptions the

application runs, then once we count four exceptions, we can set
a memory breakpoint on access for the first section of the
executable. This is normally where the OEP is located and we can
continue the execution until the breakpoint is triggered.
7. Stack – Trace back

The stack plays an important role during analysis. Since it is
natively used to keep track of correct execution, we can
also use it to get a hint about which functions were called
earlier, from which address the function we are currently in
was called, etc.
The stack is really one of your best friends during dynamic

analysis, since you can actually use it to trace back the
execution.
14.4
Packers & Tools

Used

14.4 Packers & Tools Used
When we perform manual unpacking, we need more tools

than just a debugger.
For this module, we use the following tools/plugins:

• Olly Debugger v1.10 with OllyDump v2.21.108 plugin
• ProtectionId v6.4.0
• Import REConstructor v1.7.c Final

14.4 Packers & Tools Used
Packers:
• UPX
• WinUpack
• ASPack
• PECompact
• FSG v2.0

14.5
Conclusion

14.5 Conclusion
Being able to analyze packers and extract the original

executable behind their protection layers is not usually
going to be trivial.
For this reason, through this module we aimed to give you

an overview of some generic techniques that you can use in
order to achieve your goals when fighting packers.

14.5 Conclusion
However, some commercial packers used mainly for anti-

piracy purposes, are much harder to deal with and require
much more time to analyze and manage to create a
working unpacked executable.
On the other hand, malware authors usually use much

simpler packers to not add size to their usually tiny
executables.
14.5 Conclusion
We think that, at this point, it’s time for you to go on with

the manual unpacking demonstration videos and have
some real fun.
Enjoy!

VIDEO #1
Check out the video on

Analyzing Packers (Video
1)!
To ACCESS your video, go

to the course in your
members area and click the
resources drop-down in the
appropriate module line.

VIDEO #2
Check out the video on

Analyzing Packers (Video
2)!
To ACCESS your video, go

to the course in your
members area and click the
resources drop-down in the

LAB
Put what you’ve learned to

practice with the
Packed_samples.rar!
To ACCESS your lab, go to

the course in your
members area and click
the resources drop-down
in the appropriate module
line, your file will then
download.

References

References
Here’s a list of all references linked or used in this course.
Olly Debugger v1.10
http://www.ollydbg.de/

Videos & Labs
Here’s a list of all videos and labs in this module. To ACCESS, go to the
course in your members area and click the resources drop-down in the
Analyzing Packers (Video 1)
Analyzing Packers (Video 2)
Packed_samples.rar

Malware Analysis Professional: Analyzing Packers and Manual Unpacking

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Malware Analysis Professional: Analyzing Packers and Manual Unpacking

Uploaded by

Copyright:

Available Formats

Malware Analysis

Analyzing Packers and

14.2 Well-known Entry Points

14.3 Methods to Reach the OEP

14.4 Packers and Tools Used

MAPv1: Section 02, Module 14 - Caendra Inc. © 2020 | p.2

www.ollydbg.de MAPv1: Section 02, Module 14 - Caendra Inc. © 2020 | p.3

MAPv1: Section 02, Module 14 - Caendra Inc. © 2020 | p.4

Like studying anti-reversing tricks, manual unpacking is

In order to understand what this is, try and think about

In a similar way, manual unpacking can be considered an

The concept refers to the process of studying in detail

An executable packer (a packer for executable modules) is

In the past, packers were mostly used for compression,

MAPv1: Section 02, Module 14 - Caendra Inc. © 2020 | p.7

However, these days, packers (especially the commercial

Most sophisticated packers incorporate a vast variety of

In this module, we’ll go through some simple packers and

Fortunately, there are loads of resources that can be found

Since it wouldn’t make much sense explaining the

NOTE: Your Anti-Virus may trigger a false alarm on the

MAPv1: Section 02, Module 14 - Caendra Inc. © 2020 | p.10

A few words before starting…

However, if you focus on the methodologies and concepts then

MAPv1: Section 02, Module 14 - Caendra Inc. © 2020 | p.12

As we said, our goal is to retrieve a working executable out

In order to achieve this, we need first to find the Original

In this scenario it would help a lot to be able to recognize

If you can recognize these entry points, we can search for

We wouldn’t want to let you remain curious about this, so

MAPv1: Section 02, Module 14 - Caendra Inc. © 2020 | p.15

Microsoft Visual C++ 6.0

MAPv1: Section 02, Module 14 - Caendra Inc. © 2020 | p.16

Microsoft Visual C++ 7.x

Microsoft Visual C++ 8.0-9.0

MAPv1: Section 02, Module 14 - Caendra Inc. © 2020 | p.19

Borland Delphi 6.0-7.0

MAPv1: Section 02, Module 14 - Caendra Inc. © 2020 | p.21

Microsoft Visual Basic 5.0-6.0

MAPv1: Section 02, Module 14 - Caendra Inc. © 2020 | p.22

MAPv1: Section 02, Module 14 - Caendra Inc. © 2020 | p.23

MAPv1: Section 02, Module 14 - Caendra Inc. © 2020 | p.24

Even if it’s true that each packer uses different methods to

Of course, as with everything in Reverse Engineering, you

As you already understand, there is no guide-dog in the

MAPv1: Section 02, Module 14 - Caendra Inc. © 2020 | p.26

1. Investigate near the EP for instructions such as:

Some packers, especially simple ones still used for packing

MAPv1: Section 02, Module 14 - Caendra Inc. © 2020 | p.28

2. Analyzing long loops – Find the way out.

MAPv1: Section 02, Module 14 - Caendra Inc. © 2020 | p.29

3. The ESP trick

MAPv1: Section 02, Module 14 - Caendra Inc. © 2020 | p.32

6. Exception Counting + BP Memory on access

If, for example, we know that after four exceptions the

7. Stack – Trace back

The stack is really one of your best friends during dynamic

Packers & Tools

MAPv1: Section 02, Module 14 - Caendra Inc. © 2020 | p.35

When we perform manual unpacking, we need more tools

For this module, we use the following tools/plugins:

MAPv1: Section 02, Module 14 - Caendra Inc. © 2020 | p.36

MAPv1: Section 02, Module 14 - Caendra Inc. © 2020 | p.37