Skip to main content
Every file uploaded to DECODA goes through an automated triage pipeline before you ask a single question. This gives you an immediate baseline of intelligence to work from.

​
Pipeline Stages

The triage runs asynchronously and you’ll see real-time progress updates in the chat as each stage completes.
1

File Extraction

If the upload is an archive (ZIP, RAR, or 7z), DECODA extracts the contents inside the isolated sandbox. Zip bomb detection is built in to prevent decompression attacks.Password-protected archives are handled automatically. DECODA tries the passwords most commonly used to distribute malware samples, in order: infected, malware, virus, password, and 123456. If none of these unlock the archive, it falls back to extracting without a password for unprotected files.Once extracted, DECODA selects the primary sample to analyse (preferring executables, then scripts, then documents, and falling back to the largest file). It is this extracted file - not the archive wrapper - that flows through the rest of the pipeline. The original archive name is preserved in context so you always know where the sample came from.
2

Hashing

The file is hashed using three algorithms:
  • MD5 - Legacy identifier, still widely used in threat intel feeds
  • SHA1 - Common in older detection systems
  • SHA256 - Primary identifier for lookup and threat-intel searches
For PE files, an imphash (import hash) is also computed during PE metadata extraction and is useful for clustering malware families.
3

YARA Scanning

The sample is scanned against DECODA’s built-in YARA rulesets covering:
  • Known malware families
  • Packer and protector signatures
  • Ransomware indicators
  • Suspicious API patterns
4

Binary Classification

DECODA identifies the file type and classifies it into one of 28 categories:
TypeDescription
native-peNative Windows PE (C/C++, Delphi, Rust, etc.)
dotnet.NET assembly (IL bytecode)
elfLinux ELF binary
machomacOS Mach-O binary
goGo-compiled binary
uefiUEFI firmware binary (EFI application/driver)
shellcodeRaw shellcode blob
java-jarJava JAR archive
apkAndroid APK/DEX file
office-oleLegacy Office format with OLE streams
office-ooxmlModern Office format (docx, xlsx, pptx)
pdfPDF document
onenoteOneNote file with embedded attachments
scriptScripts (PowerShell, VBScript, JavaScript, batch, Python)
lnkWindows shortcut file
htaHTML Application file
chmCompiled HTML Help file
emailEmail file (.eml/.msg)
isoISO/IMG disk image
vhdVHD/VHDX virtual disk image
msiWindows Installer package
firmwareEmbedded firmware (router, IoT)
pcapPCAP/PCAPNG network capture
evtxWindows Event Log file
registryWindows Registry hive file
prefetchWindows Prefetch file
packedPacked/protected binary (UPX, Themida, etc.)
unknownUnrecognised format
5

PE Metadata Extraction

For PE files (both native and .NET), additional metadata is extracted:
  • Compilation timestamp - When the binary was compiled (can be faked but often useful)
  • Entry point address - Where execution begins
  • Section table - Names, sizes, and entropy of each section
  • Security flags - ASLR, DEP, SEH, CFG, and other protection mechanisms

​
Reading the Triage Card

Once triage completes, a summary card appears in your chat. Here’s what each section means:

​
Detection Assessment & Verdict

At the top of the card, DECODA shows a provisional verdict that summarises everything triage observed. The verdict is one of four values:
VerdictMeaning
MaliciousStrong or compounding evidence of malicious behaviour.
SuspiciousConcerning indicators that fall short of a confident malicious call.
InsufficientNot enough was observable to make a call - never assume benign here.
BenignAffirmative clean evidence on a well-observed sample.
Beneath the verdict, an Evidence list shows the signals that drove it, strongest first. Each row is tagged with a category (such as family, injection, anti-analysis, or packing), and lower-signal heuristic indicators collapse into a single expandable group to keep the lead findings prominent. The verdict is backed by two underlying measures:
  • Confidence - how strongly the evidence supports the verdict (high, medium, or low). A single strong indicator (for example an extracted C2 address) can yield high confidence; weaker indicators only reach high confidence when they compound.
  • Observability - how much of the sample DECODA could actually see, expressed as a percentage. A heavily packed or encrypted sample has low observability, which caps confidence and steers an evidence-free result toward Insufficient rather than Benign.
Confidence and observability are different questions. Confidence asks “how sure are we about what we found?”; observability asks “how much could we see in the first place?” A sample can be highly observable yet still inconclusive, and an opaque sample with one decisive signal can still be called with confidence.
The score and verdict combine positively-weighted malicious signals with clean signals that subtract credit, so the assessment reflects evidence on both sides rather than a single red flag.
This verdict is a pre-analysis baseline, not a final answer. When you run Agent analysis, new findings are reconciled with the triage baseline: the verdict can be escalated freely as the Agent uncovers more, but it is only de-escalated toward Benign when positive clean evidence is found. The triage result acts as a floor you can build on.

​
Hashes

The MD5, SHA-1, and SHA-256 hash values for the sample. Use the SHA256 to search other threat intel platforms.

​
YARA Matches

Each match shows the rule name and the ruleset it came from. Multiple matches from different rulesets increase confidence in a classification.

​
File Classification

The detected type determines which Agent mode tools are most relevant. For example, .NET samples unlock the .NET decompiler tools, while Office documents enable OLE analysis.