• Trying to understand a program (or in our case, a piece of malware), without actually running it
• Looking at the code / structure of program

Examples of this would be:

• Analysing the sample with AVs
• Hash signatures
• Strings
• Function names

• May confirm maliciousness
• Signature-based vs. Heuristic
• Lots of techniques to counter detection

• Known malicious samples
• Sharing
• Label samples
• Reduce size of datasets for experiments

• IP addresses/URLs
• Function names
• DLLs
• Error messages
• Packer signatures

• In Windows, each word starts with an uppercase letter, e.g. SetLayout
• Imports
  • Import functions from another program
• Exports
  • Conversely, export functions to another program
• Link Libraries
  • Static linking: Copy whole code over and add to program
  • Runtime linking: Program interacts with libraries only when a function is needed
  • Dynamic linking: Program import referenced libraries as soon as program starts

But what happens if our malware was packed/obfuscated?

• AVs may not tag it as malicious
• Hash signatures will differ
• Not all strings will be shown
• Not all function names will be displayed, but some functions can hint that a sample is packed, e.g. GetProcAddress, VirtualAlloc

Basic structure of a Windows executable file

• PE header (metadata)
• Sections:
  • .text
  • .idata
  • .data
  • .rdata
  • .edata
  • .pdata
  • .rsrc
  • .reloc

Why do you need to know about it?

• Understand the inner of what you are working with
• Spot uncommon sections which could raise suspiciousness
• Possibly identify packers/obfuscation methods
• Manual unpacking
• Modifying an executable
• Research

What do you need to remember?

• What the PE file format is and its structure
• What the PE header contains
• What some of the typical sections are
• What a malware analyst could find by looking at the PE header and sections of an executable
• Examples of related tool

• www.virustotal.com
• 'strings'
• md5sum/sha1sum/sha1deep/WinMD5/etc.
• PEiD: detecting packed files
• PEView: examining PE Files
• PE Browse: browsing a PE header
• PE Explorer: browsing a PE header
• ImpREC: rebuilding the Import Table
• LordPE: dumping an executable from memory
• Dependencies: exploring DLLs and functions imported by a piece of malware.

Reverse engineering is a process where an engineered artefact (such as a car, a jet engine, or a software program) is deconstructed in a way that reveals its innermost details, such as its design and architecture.

• i.e. dissecting a product to understand how it works
• An advanced static analysis technique
• Can vary from easy... to very challenging
• Requires a lot of patience

Why learn Reverse Engineering?

• Strengthen understanding (applies to literally everything)
• Penetration-Testing
• Problem solving skills
• Solving legacy system issues
• Benefits of looking at code written by others (think open source)

Why apply it to Malware Analysis?

• Basic static analysis not always sufficient
• Complex problems require complex solutions

• Result of compiling a high-level language
• Raw binary data

• Machine code is too much hassle
• Hence, we use assembly
• Uses "mnemonics" (opcodes)
• Different instructions depending on platform
• Different syntax... e.g. Intel vs. AT&T
• Different processors require different approaches

• E.g. C, C++
• Easy to use and understand

• E.g. C#, Java
• Code → intermediate language (bytecode) → machine code

Register are data storage units closest to the processor

• Quick access
• Different registers serve different purposes

Fetch and execute cycle

Main memory (RAM)

• Data: contains values
• Code: instructions to be fetched by the CPU to execute
• Heap: allocate/free values to/from RAM
• Stack: local variable and function parameters, control program flow

What could happen if an attacker corrupted the instruction pointer?

• Modify it so they could then execute their own code in memory

Instructions

• mnemonics, e.g. ADD, MOV, SUB, XOR, INC
• May or may not have (an) operand(s), e.g. RET, POP

Operands

• Registers
• Values
• Memory addresses
• x86 → little-endian

Syntax

• A source and a destination
• Intel (<mnemonic> <dst>,<src>)
• AT&T (<mnemonic> <src>,<dst>)

cmp dst, src - The CMP instruction is identical to the sub instruction; however, the CMP instruction is used only to set the zero flag and carry flag (CF) but does not affect the operands.

test dst, src - The TEST operation returns 1, if the matching bits from both the operands are 1, otherwise it returns 0

• Eilam, E. (2011). Reversing: Secrets of Reverse Engineering. John Wiley & Sons.
• Sikorski, M., & Honig, A. (2012). Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software. No Starch Press.
• http://www.peter-cockerell.net/aalp/html/frames.html
• Penetration-Testing module: Lecture 5 Exploitation/Vulnerability Validation