Hashing, XOR & Timestamps

What is it?

Hashing (MD5/SHA-256) produces a fixed-length fingerprint you compute to identify or verify a file. XOR is a reversible byte cipher (data XOR key) common in simple obfuscation. Timestamps (Unix epoch, Windows FILETIME) convert to human dates.

Why it matters

You hash to match a sample against threat intel; you XOR-decode a lightly-obfuscated string; you convert an epoch to a date to place an event on a timeline. All three are routine analyst conversions.

Where you see it

SHA-256 of an artifact to look it up; XOR with a single-byte key to reveal a hidden URL; From UNIX Timestamp on 1724500000 to get a readable date.

What normal looks like

A hash that matches (or does not) a known value; an XOR that with the right key yields readable text; a timestamp that converts to a sensible date.

What suspicious looks like

A hash mismatch (the file is not what it claims); an XOR key that yields garbage (wrong key — brute the single byte); a timestamp read in the wrong epoch (Unix vs FILETIME) giving an absurd date.

How analysts investigate

Hash to compare against a reference; for XOR, if one key gives garbage try brute-forcing the single byte until text appears; for a timestamp, match the epoch type so the date is sensible.

Common beginner mistakes

Reading a Unix epoch as a Windows FILETIME (wildly wrong date).
Giving up on XOR after one key instead of brute-forcing the single byte.

Fingerprint, unmask, place in time

  hash:      SHA-256(sample) = 9f2a...  → look up in threat intel
  XOR:       'ip\x0b...' XOR 0x42 → 'http://evil...'  (brute the byte if unknown)
  timestamp: From UNIX Timestamp 1724500000 → 2024-08-24 ...
  three routine conversions: verify, decode, place on a timeline

Hashing verifies, XOR unmasks light obfuscation, and timestamp conversion places an event in time.

Quick check

An XOR decode with key 0x00 gives garbage but you suspect single-byte XOR. Best move?

A quick self-check — it doesn't affect your XP or progress.