Reverse Engineering Essentials — 3

Hey there!

We’ve been on the journey to understand reverse engineering in our last two blogs. Today, let’s talk about the stuff that keeps security folks up at night. We’ll see types of major malware, different reversing approaches, PE header analysis (examining the structure of Windows executables), and the benefits and limitations of both static analysis (which examines code without execution) and dynamic analysis (which observes runtime behavior).

Types of Malwares:

1. Viruses: This code attach themselves to legitimate programs and spread when you run those programs. Remember when the Emotet banking trojan made a comeback last year? It used infected Word documents that looked like innocent invoices but actually triggered malicious macros when opened. One click and boom, your computer starts spreading it to others through your contact list!
   

2. Trojans: Just like the ancient wooden horse, these pretend to be something useful while hiding their true purpose. The Raccoon Stealer 2.0 that’s been making rounds lately masquerades as a PDF converter or free game, but once installed, it silently harvests passwords from your browsers and cryptocurrency wallets.
   

3. Ransomware: This locks up your files until you pay up. The LockBit 3.0 gang has been wreaking havoc on businesses lately. Imagine coming to work and finding every important file encrypted with a ransom note demanding millions, that’s exactly what happened to several manufacturing companies this past winter.
   

4. Spyware: This secretly watches what you do and reports back to someone else. Pegasus made headlines again recently when journalists found it installed on activists’ phones, silently capturing messages, photos, and even activating microphones without anyone knowing.
   

5. Worms: Self-replicating and network-spreading. They don’t need human help to multiply.
   

6. Adware: Bombards users with unwanted ads and sometimes collects data to do so more “effectively.”
   

7. Rootkits: Grants attackers root-level (admin) access and hides their presence, making detection tough.
   

8. Fileless Malware: Lives in memory, not in files. It often uses legit system tools like PowerShell to operate stealthily.
   

Choosing Your Reversing Approach

When diving into reverse engineering, picking the right approach is like choosing the right tool for a home project. It depends on what you’re working with and what you’re trying to accomplish!

There are two main ways security researchers approach taking software apart: offline analysis and live analysis.

A. Offline Analysis is like studying blueprints. You take the program file and use special tools to transform it into something you can read. No running/ execution is required. This approach gives you a great overview of the entire program and makes it easy to search for specific functions you’re interested in. However, it’s a bit like trying to understand how to drive a car without sitting on a driver seat. You need to imagine how data moves through the program since you can’t actually see it in action.

B. In Live Analysis you still convert the code, but then you run it in a controlled environment (a debugger) and watch what happens in real-time. This shows you exactly what data the program is handling and how it affects everything else. You can see variable values change and watch the program’s decision-making process unfold before your eyes.

If you’re newer to reverse engineering, live analysis might feel more intuitive, it’s like the difference between reading about how to ride a scotty versus actually getting on one and feeling how it responds. You get immediate feedback and can watch cause and effect in action.

Both approaches have their place in a security analyst’s toolkit. Sometimes you’ll start with offline analysis to get the lay of the land, then switch to live analysis when you need to understand specific behaviors in depth!

Understanding PE Header Analysis

The Portable Executable (PE) format is like the DNA blueprint for Windows programs — it tells the operating system exactly how to load and run the file. When security analysts examine PE headers, they’re essentially reading this blueprint to understand what the program is designed to do.

What Is a PE File?

PE stands for Portable Executable, which is the standard file format for executables, DLLs, and other executable files in Windows. It’s what makes your applications run on Windows systems.

Key Components in PE Header Analysis

1. Signature Check: Every PE file starts with a signature — the famous “MZ” characters (the initials of Mark Zbikowski, one of Microsoft’s early developers). Think of this as the file’s handshake with Windows, saying “Yes, I’m a legitimate executable.” Later in the file, there’s another “PE” signature that confirms it’s specifically a Portable Executable.
   

2. Header Structure: The headers in a PE file act like a table of contents, pointing to where different parts of the program can be found. They include:

   - DOS Header (legacy compatibility header)

   - PE Header (core file information)

   - Optional Header (more detailed execution information)

   - Section Headers (describes each section of the file)
   

3. File Characteristics: These tell Windows important details about the file:

   - Entry point (where execution begins)

   - Image base address (preferred loading address)

   - Subsystem type (GUI, console application, etc.)

   - Various flags indicating special properties
   

4. Section Headers: PE files are divided into sections, like chapters in a book, each with a specific purpose:

   .text: Contains the actual program code instructions

   .data: Stores initialized variables (data the program starts with)

   .rdata: Contains read-only data like constant strings

   .rsrc: Holds resources like icons, images, and menus

   .idata: Lists all the external functions the program needs

   .pdata: Contains exception handling information

Malware analysts pay special attention to these sections as they might reveal suspicious behavior. For example, seeing executable permissions on a .data section could indicate an attempt to hide malicious code.

Examining static properties of suspicious program

When examining software without actually running it, analysts focus on these seven crucial static properties:

1. File Metadata: The basic identity card of any file includes details like creation dates, file size, permissions, and digital signatures. Suspicious files often have unusual timestamps, unexpected sizes, or missing signatures that legitimate software would typically include. These metadata elements provide the first clues about a file’s authenticity and origin.
   

2. Source Code Analysis: When available, source code reveals programming patterns, variable naming, comments, and error handling approaches. Security analysts look for hard-coded credentials, insecure functions, and suspicious API calls. Even when only decompiled code is available, the programming style and techniques can reveal much about the developer’s intentions and skill level.
   

3. External Dependencies: No program operates in isolation. Examining what libraries, frameworks, and external connections a program uses reveals its relationships with other components. Malware often relies on suspicious external connections or deliberately includes outdated libraries with known vulnerabilities that can be exploited. Legitimate software typically uses standard libraries and maintains them at secure versions.
   

4. Executable Code Properties: Binary analysis provides insights into assembly-level instructions, function calls, and compiler information. Analysts look for anti-analysis techniques like obfuscation or packing that might hide malicious intent. The complexity and structure of functions can indicate whether code was written by humans or generated by tools, and whether it contains logic designed to evade detection.
   

5. Configuration Files: These files control program behavior and reveal default settings, connection endpoints, authentication mechanisms, and feature toggles. Insecure configurations often hide in plain sight in these files. Analysts examine these files for overly permissive settings, hardcoded credentials, or references to suspicious external services that might indicate data exfiltration paths.
   

6. Embedded Resources: Programs often contain packaged files like images, localization strings, and help documentation. Malware might hide malicious components within seemingly innocent resources, using them as containers for secondary payloads. These resources can also reveal information about the target audience or origin of the software through language choices and cultural references.
   

7. PE/ELF Header Information: The executable’s structural blueprint contains section definitions, import/export tables, and memory layout information. Anomalies in these headers often indicate tampering or malicious intent. Unusual section permissions (like executable data sections) or suspicious imported functions can reveal attempts to subvert normal program execution paths.
   

Static analysis offers complete code visibility but struggles with obfuscation, while dynamic analysis reveals actual behavior but may miss conditional execution paths or detect sandbox environments.

Examining dynamic properties

Dynamic malware analysis is like watching a suspect’s behavior instead of just examining their belongings. By executing malicious code in a controlled environment, security analysts can observe exactly what the malware does, revealing its true intentions and capabilities.

How It Works?

When performing dynamic analysis, security professionals run the suspicious program in an isolated “sandbox” environment that mimics a real system. As the malware executes, they monitor:

• System changes (files created, modified, or deleted)

• Registry modifications

• Network connections and data transfers

• Process creation and termination

• Memory usage and manipulation

Key Benefits

Dynamic analysis provides critical insights that static examination might miss:

• Reveals obfuscated behavior: Many modern malware samples use encryption, packing, or obfuscation to hide their true code. Dynamic analysis cuts through these disguises by watching what actually happens when the code runs.
  

• Exposes multi-stage attacks: Some malware acts as a “dropper,” initially appearing harmless but later downloading more dangerous payloads. Dynamic analysis catches these secondary infections that static analysis would miss.
  

• Demonstrates real impact: By seeing exactly how the malware interacts with a system, analysts can better understand its damage potential and develop more effective countermeasures.
  

• Reveals environment-specific behaviors: Some malware behaves differently depending on the environment, targeting specific configurations or activating only under certain conditions. Dynamic analysis can test these variations.
  

Significant Challenges

Despite its benefits, dynamic analysis comes with important limitations:

• Anti-analysis techniques: Sophisticated malware can detect when it’s running in a sandbox by checking for virtual machine artifacts, monitoring for user activity (mouse movements, keyboard inputs), or looking for analysis tools. When detection occurs, the malware might:
  

• Remain dormant to avoid revealing its true behavior
  

• Execute benign code instead of malicious functions
  

• Crash deliberately to prevent analysis
  

• Time and resource intensity: Proper dynamic analysis requires dedicated infrastructure and expertise. Each sample needs its own isolated environment and may require significant observation time to reveal all behaviors.
  

• Incomplete execution paths: Malware might contain conditional execution paths that activate only under specific circumstances (dates, presence of certain applications, geographic location). A single analysis run might miss these alternate behaviors.
  

• Environmental contamination risk: Even with careful isolation, there’s always some risk of malware escaping containment, especially when dealing with previously unknown threats.
  

Best Practices for Safe Dynamic Analysis To minimize risks while maximizing insights:

• Use dedicated, disposable systems isolated from production networks
  

• Configure analysis environments to match target systems (OS, applications, configurations)
  

• Employ network monitoring tools to capture communication attempts
  

• Implement strict firewall rules to contain any unexpected behaviors
  

• Combine multiple analysis runs with varying environmental conditions
  

• Reset the environment completely between tests to prevent cross-contamination
  

By combining dynamic analysis with static examination techniques, security professionals can develop a comprehensive understanding of malware capabilities and design appropriate defenses.

See ya next Thursday!

Reverse Engineering Series Link