CTMTCS SII P4: Malware Analysis & Reverse Engineering Even Semester 2025-26
Lecture Note#1: Basic Static Analysis
Lecturer: Dr. Himanshu B Patel Scribes: [Link] CS 2nd year, Semester II
Note 1: LaTeX template courtesy of UC Berkeley EECS dept.
Note 2: This document might contain hyperlinks that require an active internet connection.
Note 3: Do not execute unknown samples on host; use controlled environment for dynamic analysis.
Note 4: Share samples via internal LMS only; use hash/metadata for discussion; follow lab safety SOP.
Disclaimer: This lecture note is prepared for the students of the School of Cybersecurity and Digital Foren-
sics, National Forensic Sciences University and has not been subjected to the usual scrutiny reserved for
formal publications. They may be distributed outside this class only with the Instructor’s permission.
1.1 Introduction to Malware Analysis
Malware analysis is the systematic process of examining a suspicious program to understand its function-
ality, behavior, capabilities, and impact without necessarily executing it.
The primary goals of malware analysis are:
Identify what the program does
Determine how it infects or persists
Extract Indicators of Compromise (IoCs)
Support forensic investigation and incident response
Develop detection signatures
Two major approaches exist:
1. Static Analysis – Study without executing
2. Dynamic Analysis – Observe while executing
1.2 Malware Analysis Methodology
Professional malware analysis follows a structured methodology rather than random tool usage.
1. Triage (hashing, type identification)
0 These notes cover Unit-I foundations: safe lab setup, hashing, strings, FLOSS, PE headers/sections, imports-based capa-
bility inference, and tool-driven triage using DIE, PEStudio, and CFF Explorer.
1-1
Lecture Note #1: Basic Static Analysis 1-2
2. Static inspection (strings, headers, imports)
3. Behavioral hypothesis formation
4. Deeper analysis (debugging/dynamic)
5. Reporting and IoC extraction
This systematic approach ensures:
Faster investigation
Reduced risk
Reproducible results
Forensic defensibility
In this lecture note, we focus on Basic Static Analysis.
1.3 Static vs Dynamic Analysis
Aspect Static Analysis Dynamic Analysis
Execution Required No Yes
Safety High Risky
Speed Fast Slow
Tools Strings, PEStudio Sandbox, Debugger
Detection Evasion Limited Better
Static analysis is always the first step in professional malware investigation.
1.4 Forensic Importance of Static Analysis
Static analysis treats a suspicious executable as digital evidence.
No infection risk
Preserves system integrity
Suitable for forensic labs
Useful for quick triage
Provides immediate intelligence
Hence, analysts follow the rule:
“Never run unknown binaries without inspection.”
Lecture Note #1: Basic Static Analysis 1-3
1.5 Hashing – Digital Fingerprinting
A cryptographic hash uniquely identifies a file.
Command
certutil =hashfile [Link] MD5
certutil =hashfile [Link] SHA256
Uses:
File integrity verification
Threat intelligence lookup
Malware identification
Chain of custody in forensics
Even one-bit change produces a completely different hash.
1.6 Signature-Based Detection
Antivirus solutions primarily rely on signature matching.
A signature is a unique byte pattern that identifies known malware.
Advantages:
Fast detection
Low false positives
Disadvantages:
Fails against new or obfuscated malware
Easily bypassed by packing or encryption
The EICAR file demonstrates how signature detection works in practice.
1.7 Case Study: EICAR Test File
EICAR is a harmless test string used to verify antivirus functionality.
Although not malicious, antivirus flags it because:
Lecture Note #1: Basic Static Analysis 1-4
Detection is signature-based
Pattern matches known test signature
This demonstrates how signature detection works.
1.8 Strings Extraction
Programs often contain readable strings such as:
URLs
File paths
Commands
Error messages
Registry keys
Command
strings [Link] > [Link]
Strings frequently reveal program intent without execution.
1.9 Entropy and Packing Detection
Entropy measures randomness in a file section.
Low entropy (≈ 4–5) → Normal code/data
High entropy (≈ 7–8) → Packed or encrypted
Packed malware hides its content to evade:
Strings extraction
Signature detection
Static analysis
Thus entropy is an early indicator of obfuscation.
Lecture Note #1: Basic Static Analysis 1-5
1.10 FLOSS – Decoding Obfuscated Strings
Malware hides strings using encoding or encryption.
FLOSS extracts:
Stack strings
Decoded strings
Runtime generated strings
floss [Link] > [Link]
Difference:
Strings FLOSS
Plain text only Hidden + decoded
Basic Advanced
Strings vs FLOSS (Static Intelligence Extraction)
Binary ([Link])
Strings Tool FLOSS
Finds plain readable strings Finds stack/decoded/hidden strings
(URLs, paths, messages) (obfuscated intent)
Analyst Inference
Intent + IoCs + Next Steps
1.11 Portable Executable (PE) Structure
Windows executables follow the PE format.
Common sections:
.text – code
.data – variables
.rdata – constants
Lecture Note #1: Basic Static Analysis 1-6
.rsrc – resources
High entropy often indicates packing or encryption.
High-Level PE Layout (Conceptual)
DOS Header (MZ)
DOS Stub (legacy)
NT Headers (PE)
File Header + Optional Header
Section Table (Section Headers)
.text (Code)
.rdata (Read-only data / constants)
.data (Global variables)
.rsrc (Resources: icons, dialogs, version info)
Other / Custom Sections (may indicate packing/obfuscation)
1.12 Import Table Analysis
Imports show capabilities of the program.
Example APIs:
CreateFile – file operations
WriteFile – data writing
RegSetValue – registry persistence
InternetOpen – network communication
CreateProcess – process creation
Rule:
Imports tell us what the program can do.
Lecture Note #1: Basic Static Analysis 1-7
From Imports to Behavior (Capability Inference)
Observed Imports (APIs)
CreateProcessA, WriteFile, RegSetValueExA, InternetOpenA
Capabilities
– Process creation
– File write/modify
– Registry modification
– Network communication
Likely Behaviors
– Dropper/downloader
– Persistence via Run keys
– C2 communication / data exfiltration (possible)
Static Verdict (Triage)
Suspicious → prioritize deeper analysis (debugging/sandbox/VM)
1.13 Tools Used in Lab
Tool Purpose
Detect It Easy File type / packer detection
certutil Hash calculation
Strings Extract readable text
FLOSS Decode hidden strings
PEStudio Sections / Imports / Indicators
CFF Explorer Deep PE internals
1.14 Case Study: CrackMe Analysis
Students analyzed a CrackMe executable.
Observations:
Normal entropy
Visible strings: password, success, error
Imports: MessageBoxA
No network or persistence APIs
Lecture Note #1: Basic Static Analysis 1-8
Inference:
It is likely a password checking program.
This demonstrates how static analysis predicts behavior without execution.
1.15 Standard Static Analysis Workflow
1. Calculate hash
2. Identify file type (DIE)
3. Extract strings
4. Run FLOSS
5. Inspect PE structure
6. Analyze imports
7. Infer behavior
Lecture Note #1: Basic Static Analysis 1-9
Workflow Diagram: Basic Static Analysis Pipeline
Start: Suspicious File ([Link])
Hashing (MD5/SHA256)
certutil -hashfile
File Identification
DIE: PE32/PE64, Compiler, Packer, Entropy
Readable Strings
Sysinternals Strings → [Link]
Hidden/Obfuscated Strings
FLOSS → [Link]
PE Triage
PEStudio: Sections, Imports, Indicators
Deep PE Internals
CFF Explorer: Headers, Entry Point, Import Directory
Inference & Report
Capabilities + Suspected Behavior + Risk Level
1.16 Limitations of Static Analysis
Although static analysis is safe and fast, it has limitations:
Cannot observe runtime behavior
Fails against heavy packing/encryption
Cannot detect dynamically generated APIs
May miss logic triggered by environment or user input
Lecture Note #1: Basic Static Analysis 1-10
Therefore, static analysis is usually followed by dynamic analysis and debugging.
1.17 Capability vs Behavior
Static analysis reveals what a program can do, not necessarily what it will do.
Imports show capabilities
Strings show intent
Execution confirms behavior
Thus, conclusions drawn from static analysis are hypotheses that must be validated dynamically.
1.18 Analyst Mindset During Static Analysis
Effective malware analysis is not about blindly running tools.
An analyst should:
Form hypotheses from evidence
Correlate multiple observations
Avoid assumptions
Validate findings through multiple tools
Treat each file as forensic evidence
Tools assist analysis, but reasoning drives conclusions.
——— End of the Document ———
The most dangerous phrase in the language is: ‘We’ve always done it this way.
– Grace Hopper