Resource and contribution
Introduction to Malware Threats and Malware Blackbox Analysis was a proprietary, contained lab resource package that I shared in December 2019 during my Trend Micro work. This entry records the resource and my distribution contribution without assigning sole authorship to its individual materials.
The public overview explains the analytical method. The proprietary package, lab configuration, samples, and internal exercises are not reproduced here.
What blackbox analysis asks
Blackbox analysis approaches a program through its observable inputs, outputs, and effects. Rather than beginning with the implementation of each function, the analyst asks what changed in the observed environment and how those changes relate to the program under examination.
That can include processes, files, configuration, or communication, depending on the available collection. A visible change is evidence to investigate, not an explanation of every internal path that produced it. Conversely, a behavior that was not observed may depend on conditions the exercise did not provide.
- Define the question
State the behavior being investigated and the evidence needed to recognize it.
- Record a baseline
Describe the relevant starting state so later differences are meaningful.
- Compare observations
Identify new or changed artifacts within the observation interval.
- Test the explanation
Correlate changes with the program and consider alternative causes.
A synthetic state-comparison example
The following code operates on fictional filenames held in memory. It launches no program, reads no files, and is a new educational example rather than code from the lab.
before = {'demo-settings.ini', 'baseline.log'}
after = {'demo-settings.ini', 'baseline.log', 'new-output.txt'}
created = after - before
removed = before - after
assert created == {'new-output.txt'}
assert removed == set()The comparison identifies a newly listed file. It cannot establish the creator, the contents, or the purpose. A real investigation would need evidence such as process-linked file events and timestamps before attributing the change to a particular program. A filename-only comparison also misses changes to the contents of a file that retains the same name.
Questions to preserve in the analysis record
| Observation | Follow-up question |
|---|---|
| A new artifact appeared | Which process or system activity produced it? |
| An existing artifact changed | What changed in its contents, configuration, or metadata? |
| A connection was observed | Which process initiated it, and what does the capture actually reveal? |
| No expected effect appeared | Were the trigger conditions and collection visibility sufficient? |
These questions make the method useful without overstating what an individual observation proves. They also explain why repeatability depends on a documented starting state and consistent collection, rather than merely running the same program again.
Connection to reverse engineering
Blackbox observations can guide a later static investigation toward the functions and conditions that might explain the observed effects. Static analysis can then suggest a new question to test. Neither view automatically replaces the other: one exposes implementation possibilities, while the other captures behavior under particular conditions.
For an openly reproducible exercise, the site’s reverse-engineering Lab uses a separate benign fixture with documented inputs and outputs. It is independent of this proprietary resource.