Languages, platforms, and executable artifacts

Four different questions

A source repository and an executable answer different questions. A repository shows one set of implementation choices. A built artifact reflects a particular target, toolchain, configuration, and revision. Begin by separating the source language, the processor architecture, the container format, and any required runtime. None is a substitute for the others.

For this lesson, imagine two versions of the same harmless status-printing program. One is compiled as native code and the other runs through a language runtime. Their visible output can match even though their startup sequence, dependencies, and error paths differ. That distinction carries into malware implementations: a capability name does not tell you how the underlying program is represented.

Model the build target

{
  "example": "status-printing demonstration",
  "source_language": "C",
  "target_os": "Windows",
  "target_architecture": "x64",
  "artifact_format": "PE",
  "build_revision": "record separately"
}

This is a descriptive record, not a compiler configuration. It deliberately keeps architecture separate from operating system and file format. The same record would need different values for another target; changing the text alone would not transform a binary or make platform-specific calls portable.

Native code, managed code, and scripts

When reading native source, track the boundary between project code, linked libraries, and operating-system services. For managed implementations, include the runtime in your explanation of execution. For scripts, include the interpreter and the context in which it is invoked. A process name is not enough to establish which component supplied the behavior.

Windows PE, Linux ELF, and macOS Mach-O are distinct executable formats. This course uses small platform-independent models where possible, then identifies platform assumptions when a mechanism depends on them. It does not treat a Windows API example as an implementation for every operating system.

What source can establish

A checked-in file can be unused, conditionally compiled, or changed after the binary under investigation was built. Before claiming that a sample contains a feature, connect the source to a build artifact or confirm the behavior independently. In your notes, distinguish “present in this repository” from “included in this build” and “observed during this run.”

Exercise

A repository contains a Linux build script and a Windows-specific source file. Does this prove its Linux executable uses that Windows code? List the next pieces of evidence you would request.

Check your understanding

No. Inspect which files the build includes, the conditional compilation settings, and the artifact being discussed. The existence of a file is not evidence that it participates in every build. You should finish this lesson able to describe a target without confusing its language with its platform.