Nicolas Brulez

Virus Researcher
 Agenda
§ Introduction

§ First Steps
– File Format Analysis : Is my file packed?
– Unpacking
– Disassembly

§ Unpacking Demo

§ Finding interesting code in Malwares (Basic but works most of the time)
– WinMain
– Imports
– Threads
– Strings

§ R.E Example:
– Malware Protocol Reverse Engineering

2
 Introduction
§ Reverse Engineering Malcode is most of the time a fairly
easy task (Easier than porting Linux to a closed device)

– We don’t need to patch the Binary (most of the time)

– We don’t need to understand everything
– We can skip big sections of code
– We can make big assumptions
– We don’t need to fix the unpacked files most of the time,
except if we want to debug it

3
 First Steps: Is my file Packed?
§ What is Packing anyway ?

– Allows to compress/encrypt applications

– You can’t see the code of the application using a
disassembler, you need to unpack it first.
– Packers compress applications and add a small loader
to the file.
– The loader will uncompress the binary in memory,
resolve imports, and call the Original Entry Point (OEP).
– We need to find OEP and dump the process to disk, and
rebuild the import table.

4
 First Steps: Is my file Packed?
§ Is the last section executable ?

§ Is the first section writeable ?

§ Is the first section's raw size null ?

§ Is the Entry Point starting in the last section ?

§ Check the section names

§ Check the Import Table : Very few imported functions ?

§ Check the strings : no strings at all ?

§ Is the Raw Size way smaller than the Virtual Size?

Compressed!
5
 First Steps: Is my file Packed?

6
 First Steps: Unpacking
• Unpacking knowledge is very handy for Reverse Engineers.

• Most malwares are packed to hide their real code from

Disassemblers.

• There are a lot of different PE packers and PE protectors out

there, and many have no public unpackers.

• Fortunately, most packers (and “Protectors” :P) are easy to

remove.

7
 First Steps: Unpacking

§ Find the Original Entry Point

– Trace slowly until you jump to the real program code.
– Use Static Disassembly to find the jump to original entry point.
– Smart use of hardware breakpoints. (Write access is your
friend).
– Breakpoints on API Functions.
– Use Stack (pushad is your friend)

§ Dump the process to disk

– Using tools such as LordPE or Imprec Process dumpers.

8
 First Steps : Unpacking
§ Reconstruct the Import Table
– Trace the packer’s code and find where the IAT handling
is, so you can grab information about the import table
and reconstruct it manually, eventually. (or patch the
protector so it will not destroy the imports at all J )

– You can just use “Import Reconstructor” to reconstruct

the import table and get ride of the boring work most of
the time.
– Sometimes we need to write plugins for Imprec, but
usually it only takes a dozen minutes.

9
 Disassembly
§ Once our file has been unpacked, we can start
disassembling it, looking for malicious code.

10
 Finding interesting code in Malwares
§ WinMain

For malware written in C/C++, you will quite often find interesting
information right at the WinMain function.

WinMain is NOT the first thing being executed in a binary, unlike

most people think. There are a few things done by the compiler first.
IDA usually will identify the WinMain function for us, but it is
fairly easy to do it manually, by looking at functions parameters near
the entry point. (and API functions call, eg: GetModuleHandleA).

Sometimes, malcode will just make a Mutex and create various

threads at WinMain. It is therefore very easy to find the main
functions of the malware.

12
 Finding interesting code in Malwares
§ Imports
You can use imports to find interesting parts of
a malcode. Eg:

• Registry Functions to find whether it is adding binaries to

XP firewall’s whitelist, or if it’s going to start when
Windows is loading etc.
• Socket Functions to find whether it is binding a port on
local machine, trying to connect on remote websites,
sending informations on remote machines etc.
• File Functions to find whether it drops files, or copy itself
to the windows directory, etc
• Process Functions to find whether it starts a process, or
looks for running processes (AV, firewalls...) and terminate
them etc.

13
 Finding interesting code in Malwares
§ Threads

A lot of malwares are using threads to run their different payloads:

– Scanning hard drives for WAB Files

– Scanning memory for Firewalls and Anti Virus programs to
kill them
– Sending infected emails to infect people
– Binding a shell on a port for remote access
– etc...

14
 Finding interesting code in Malwares
§ Strings

Strings are also a quick way to find interesting code, as many

malcode authors are just too lazy (or naive, because they
think the fairly new packer they found is going to save them)
to encrypt them.

Once unpacked, you can often use strings to find protocols

keywords, website used to download new malwares, or upload
stolen information (keylogging) etc.

15
 Example: A Proxy Trojan Protocol R.E
§ Don’t forget that most Malcode authors are naives (or
stupids).

§ This one was packed with an old version of Asprotect

(Commercial PE Protector), yet we don’t need to rebuild the
file 100%, if we have 98% of the imports rebuilt, it’s all we
need to do static analysis.(yes, we can be lazy too J )

§ They thought that making their console application, a

« GUI » application, would trick someone.. Unfortunately, it
did not work. J

16
 Example: A Proxy Trojan Protocol R.E
§ I saw many interesting strings inside the binary:

17
 Example: A Proxy Trojan Protocol R.E
§ The malcode author is so nice with us

18
 Example: A Proxy Trojan Protocol R.E
§ When we run this malcode we will never see those strings
on our screen.
§ I assumed they were lazy or naives, and made their
application a GUI one, so we actually don’t see anything.
§ Fire up your favorite PE Editor and make it a Console
application.

19
 Example: A Proxy Trojan Protocol R.E

§ Looks good, doesn’t it?

§ Now we can reverse the protocol and see nice information

in the console window. Helps finding out what’s wrong with
our parameters.

20
 Example: A Proxy Trojan Protocol R.E
§ Let’s try to Reverse Engineer the remote command feature.

§ Does it match « CTL »?

21
 Example: A Proxy Trojan Protocol R.E
§ The code is looking for « CTL » inside a buffer, and if we
scroll up a little bit, we will find that, it’s actually, a socket
buffer. (The recv functions is a good hint).

22
 Example: A Proxy Trojan Protocol R.E
§ We learn that we need to send « CTL findme something »
here.

23
 Example: A Proxy Trojan Protocol R.E
§ Third parameter is used as an index to select the command
to execute.

24
 Example: A Proxy Trojan Protocol R.E
§ Switch Jump Table

– CTL 1 findme : This will Clean Registry and ExitProcess

– CTL 2 findme 31337 : This will change the server Port.
– CTL 3 findme 94 : This will change the collector Port.
– Etc ...

25
 Example: A Proxy Trojan Protocol R.E
§ All the other commands work the same way, so we can
reverse engineer the whole proxy protocol.
§ We could easily « flood » the collector with bogus
information by chaning the interval to something very
small. He most likely use some sort of logging, to know
which computers are infected.

§ This one was easy, but most of the malwares are THAT
easy.

26
 Questions?
§ If you have any questions, please talk SLOOOWLY, or just
come to talk to me after the presentation. (Better :p)

§ Thanks J

nbrulez@websense.com

http://WebsenseSecurityLabs.com

27