[CSSCTF] Digital Forensics Writeup: Nexus Series#
Author: k0z1l
Category: Digital Forensics / Audio DSP / Disk Carving / PCAP Analysis / Linux Artifacts
Flag Format: CSSCTF{...}
1. The False Timeline#
1.1. Challenge Description & Scenario#
Nexus Incident Response recovered a filesystem image from Relay NX-17 after an unauthorised emergency key export. Investigators concluded that Relay Administrator KAI-7 performed the export at approximately 03:17.
There is one problem. KAI-7 had already disconnected. Someone wanted the investigation to end there.
Reconstruct the true incident timeline and recover the stolen emergency access key. Flag format:
CSSCTF{...}Attached Asset: System disk image
nexus_relay.img(128 MB).
1.2. Initial Reconnaissance & Ext4 Filesystem Analysis#
Inspecting magic bytes of nexus_relay.img:
- At offset
0x400(Linux Ext filesystem Superblock block):- Bytes at
0x438:0x43Aread53 ef(0xEF53Little-Endian). - This identifies standard Linux Ext4 (
s_magic = EXT4_SUPER_MAGIC).
- Bytes at
Extracting the directory hierarchy using Python’s ext4 library exposes the critical artifacts:
/etc/machine-id: Machine identifier string (8f3b2a1c9e4d56781234abcd567890ef)./home/kai/.bash_history: Bash command history for userkai./opt/nexus/lib/exporter.py: Python module detailing key derivation and encryption routines./var/cache/nexus/.ekey-cache: Binary payload containing the stolen emergency key package./var/lib/nexus/metadata.db: SQLite database storing user sessions and export jobs./var/log/auth.log: SSH authentication logs and user session transitions./var/log/audit/audit.log: Linux Auditd kernel log recording exact syscall events./var/log/nexus/relay.log: Application runtime logs from Relay NX-17.
1.3. True Timeline Reconstruction#
1.3.1. Fabricated Evidence in relay.log#
Initial triage attributed the key export to KAI-7 at 03:17 based on /var/log/nexus/relay.log:
| |
The adversary planted or manipulated this application log entry to frame Administrator KAI-7.
1.3.2. KAI-7’s Alibi in auth.log#
Cross-referencing authentication records in /var/log/auth.log:
02:52:11: Administratorkailogged in via SSH from IP10.5.21.99, assigned Session 4 (New session 4 of user kai).02:55:01:kaichecked service health:sudo /bin/systemctl status nexus-relay.03:05:41:kaidisconnected and fully terminated the SSH session:1 2 3Oct 1 03:05:41 nx-17 sshd[1822]: pam_unix(sshd:session): session closed for user kai Oct 1 03:05:41 nx-17 systemd-logind[789]: Session 4 logged out. Waiting for processes to exit. Oct 1 03:05:41 nx-17 systemd-logind[789]: Removed session 4.03:10:02: Asuprivilege escalation to service accountsvc-relaywas performed byroot:1 2Oct 1 03:10:02 nx-17 su[1890]: Successful su for svc-relay by root Oct 1 03:10:02 nx-17 su[1890]: pam_unix(su:session): session opened for user svc-relay(uid=998) by (uid=0)- Conclusion: KAI-7 disconnected more than 11 minutes prior to 03:17. This provides an absolute alibi.
1.3.3. Process Execution Traces in audit.log#
Linux Auditd captures immutable, kernel-level syscall records with precise Unix Epoch timestamps:
audit(4157542380):kai(uid=1001, auid=1001, session=4) executedsystemctl status nexus-relay.audit(4157543482): A shell (sh) was spawned byuid=998 (svc-relay)at03:11:22.audit(4157543568): Execution of the emergency key export utility:1 2type=SYSCALL msg=audit(4157543568.045:92): arch=c000003e syscall=59 ... uid=998 ... comm="nx-export" exe="/opt/nexus/bin/nx-export" key="nexus_export" type=EXECVE msg=audit(4157543568.045:92): argc=2 a0="/opt/nexus/bin/nx-export" a1="--emergency"- Execution Timestamp: Epoch =
4157543568(03:12:48). - Executing User:
uid=998 (svc-relay)(not KAI-7).
- Execution Timestamp: Epoch =
audit(4157543712)(at03:15:12): Evidence tampering via Timestomping:Decoded proctitle hex:1type=PROC_PROCTITLE msg=audit(4157543712.500:99): proctitle=746f756368002d72002f6574632f6d616368696e652d6964002f7661722f63616368652f6e657875732f2e656b65792d6361636865touch -r /etc/machine-id /var/cache/nexus/.ekey-cache.
Adversary Intent: Copy timestamps from/etc/machine-idonto.ekey-cacheto conceal its creation time.
1.3.4. Session & Job Metadata in SQLite metadata.db#
Querying /var/lib/nexus/metadata.db:
- Table
sessions:- KAI-7’s Session:
session_uuid = b7a1c8d9-23f4-4d8e-9c12-78d1f2a4b679(terminated at4157543141$\approx$03:05:41). svc-relaySession:session_uuid = aab0c8b2-f8b1-4f11-9a72-6d8123a1005a(started at4157543482$\approx$03:11:22).
- KAI-7’s Session:
- Table
jobs:- Job ID 2:
emergency_exporton resourceemergency-core, statuscompleted. - Created Timestamp:
created_at = 4157543568. - Responsible Session:
session_uuid = aab0c8b2-f8b1-4f11-9a72-6d8123a1005a(svc-relay).
- Job ID 2:
1.3.5. Timeline Reconciliation Table (True Timeline vs. False Timeline)#
| Timestamp (UTC) | Epoch | Real Incident Event (True Timeline) | Evidentiary Source | Fabricated Narrative (False Timeline) |
|---|---|---|---|---|
02:52:11 | 4157542331 | KAI-7 SSH login (Session 4) | auth.log | |
02:55:01 | 4157542501 | KAI-7 checks relay status | auth.log, audit.log | |
03:05:41 | 4157543141 | KAI-7 logs out and terminates SSH session | auth.log, metadata.db | |
03:10:02 | 4157543402 | Root performs su transition to svc-relay | auth.log | |
03:11:22 | 4157543482 | svc-relay initializes interactive shell | audit.log, metadata.db | |
03:12:48 | 4157543568 | svc-relay executes nx-export --emergency to steal key | audit.log, metadata.db | |
03:15:12 | 4157543712 | Adversary timestomps .ekey-cache via touch -r | audit.log | |
03:17:03 | 4157543823 | No background process activity recorded | Quiescent system | Fabricated log in relay.log blaming KAI-7 |
1.4. Recovery & Decryption of Emergency Access Key (.ekey-cache)#
Examining /opt/nexus/lib/exporter.py:
| |
Packet layout of .ekey-cache (61 bytes):
- Bytes 0..7 (8 bytes): Magic header
b"NXKEY_V1" - Bytes 8..19 (12 bytes): AES-GCM IV/Nonce (
ceb41b1eb7393aafd5229166) - Bytes 20..60 (41 bytes): AES-GCM Ciphertext and 16-byte Authentication Tag.
Artifact values derived from the True Timeline:
machine_id=8f3b2a1c9e4d56781234abcd567890efsession_uuid=aab0c8b2-f8b1-4f11-9a72-6d8123a1005a(svc-relay)event_epoch=4157543568
1.5. Annotated Solution Script (Python)#
| |
1.6. Flag#
| |
2. Signal Fracture#
2.1. Challenge Description & Scenario#
KBR-17 came back online for only fourteen seconds before the Nexus fabric collapsed again. A passive tap captured the relay’s final uplink, and technicians recovered the relay drive exactly as it was after emergency shutdown.
Two details survived in the maintenance notes: the scheduler catalog was intact even though the spool index had been purged and uplink retries may have produced more than one copy of the same fragment.
Flag Format:
CSSCTF{...}Provided Assets:
KBR17_relay.img(64 MB - relay storage image).KBR17_uplink.pcap(5.3 KB - uplink network packet capture).
2.2. Disk Image & Network Packet Reconnaissance (PCAP & Disk Recon)#
2.2.1. Disk Image Analysis (KBR17_relay.img)#
Examining MBR partition table at sector 0:
- Partition 0: Starts at LBA
2048(offset1,048,576bytes), 24 MB. Linux Ext4 labeledNEXUS_SYS. - Partition 1: Starts at LBA
53248(offset27,262,976bytes), 32 MB, type0xda(Non-FS raw data).
Extracting Partition 0 (NEXUS_SYS) reveals vital logs and specifications:
/opt/nexus/docs/fragment-format.txt: Protocol specification for fragment data structures./home/operator/maintenance.txt: Note 17-B confirming:- The scheduler catalog retains authoritative fragment sequences and expected SHA-256 hashes.
- The raw spool operates as a circular Ring Buffer: purging merely unlinks catalog references while leaving raw sector data intact.
- Network capture may contain duplicate fragments caused by transmission retries.
/var/log/nexus/transfer.log: Log of the emergency burst transfer:$\implies$ Transfer1 2 32101-03-17T02:18:41Z relay17 transfer_mgr[418]: object=emergency_burst_17 session=6E2C17A9 fragments=8 queued 2101-03-17T02:18:46Z relay17 uplinkd[502]: session=6E2C17A9 retry requested seq=6 2101-03-17T02:18:47Z relay17 uplinkd[502]: session=6E2C17A9 retry acknowledged seq=6session = 0x6E2C17A9, objectemergency_burst_17comprises exactly 8 fragments (seq 0 to 7). Fragment 6 underwent retry!/var/lib/nexus/scheduler/relay.db: SQLite database holding thefragmentstable, providing expected SHA-256 hashes for all 8 fragments.
2.3. Dissecting the NXFR Fragmentation Architecture#
Per /opt/nexus/docs/fragment-format.txt, NXFR packets follow Big-Endian byte order:
| Offset | Size | Data Type | Field Description |
|---|---|---|---|
0x00 | 4 bytes | ASCII | Magic header: NXFR (0x4E 0x58 0x46 0x52) |
0x04 | 4 bytes | uint32 | session_id (0x6E2C17A9) |
0x08 | 2 bytes | uint16 | sequence (0-indexed fragment sequence number) |
0x0A | 2 bytes | uint16 | total_fragments (total fragment count: 8) |
0x0C | 4 bytes | uint32 | payload_length (length of fragment payload) |
0x10 | 4 bytes | uint32 | payload_crc32 (CRC32 checksum of payload) |
0x14 | … | bytes | Fragment payload data |
Crucial Detail: The SHA-256 checksum stored in relay.db applies strictly to the payload bytes, excluding the 20-byte NXFR header.
2.4. Recovery and Integrity Verification of 8 Fragments (Fragment Carving)#
Querying table fragments in relay.db for session 6E2C17A9:
| Seq | Source Type | Status | Expected SHA-256 (Scheduler Catalog) | Actual Recovery Location |
|---|---|---|---|---|
| 0 | SPOOL | PURGED | fdde3a6dc2c9d43e0bbf21b1e90d1214d5776405397ab54426ff7bb6bec8831d | Disk KBR17_relay.img @ offset 0x1a40000 |
| 1 | CACHE | RESIDENT | 82fc22cae997c805035ef22fd98c260c626c67aaaef45301236bc549897e47ae | File /var/cache/nexus/objects/82fc22cae997c805.blob |
| 2 | SPOOL | PURGED | 5cd4fd1f9bdc1360dc272362ee421b4f62f2818c7d68332440042c3e46b8f732 | Disk KBR17_relay.img @ offset 0x1d20000 |
| 3 | UPLINK | CAPTURED | 3258da54f56a49e79a1719d9145a6cd82691a0d2b10a9a1e8782e9cacf507dc6 | PCAP KBR17_uplink.pcap (Packet 8) |
| 4 | CACHE | RESIDENT | 4e86900e878981dcaec4e63b381395496598282d68f2a63e578350bdccfe7daa | File /var/cache/nexus/objects/4e86900e878981dc.blob |
| 5 | SPOOL | PURGED | 27ffcedf5e0e4bbec59c36c662aa1397d729c9a8bcd6005131a048856efb3e58 | Disk KBR17_relay.img @ offset 0x2090000 |
| 6 | UPLINK | RETRIED | fa9dbecb99768ea4d8470546b270845127278e797e09f71073df7e5658bdabae | PCAP KBR17_uplink.pcap (Packet 10; Packet 9 was corrupted) |
| 7 | UPLINK | CAPTURED | a9d2e70930248e74b776c1db737637d2e2a354308d216921225216288a94b7d0 | PCAP KBR17_uplink.pcap (Packet 11) |
Resolving Seq 6 Conflict:
The PCAP contains two packets claiming seq = 6:
- Packet 9: SHA256 =
a6b0308e...$\rightarrow$ Mismatches catalog (corrupted attempt triggering retry). - Packet 10: SHA256 =
fa9dbecb...$\rightarrow$ Matches scheduler catalog 100% (valid retry).
2.5. Archive Reconstruction and Flag Extraction#
With all 8 payloads verified:
- Concatenate payloads in ascending order from
seq 0toseq 7. - Total concatenated size: 6,725 bytes.
- Examining header bytes:
1f 8b 08 08followed by original filenameemergency_burst_17.tarconfirms a GZIP compressed TAR archive (.tar.gz). - Decompressing GZIP yields a 10,240-byte TAR archive containing 3 files:
burst_metadata.jsontelemetry.binfinal_message.txt
- Reading
final_message.txt:1 2 3 4 5 6KBR-17 EMERGENCY BURST // FINAL RECOVERY Origin: Kuiper Belt Relay 17 Event: The Severance The relay did not fail silently. Its final burst survived as fragments across the spool ring and uplink. Authorization token: CSSCTF{fragment_t3ll_th3_st0ry}
2.6. Annotated Solution Script (Python)#
| |
2.7. Flag#
| |
3. Ghost Frequency#
3.1. Challenge Description & Scenario#
Following the collapse of the Nexus Fabric at relay station KBR-17, blackbox audio telemetry (
KBR17_blackbox.wav) was recovered from the station’s monitoring sensors.The transmission was heavily interfered with by an uncharacterized “Ghost Frequency”. Demodulate the covert radio signal hidden within to recover the final emergency transmission.
Flag Format:
CSSCTF{...}Provided Asset: Audio file
KBR17_blackbox.wav(22 MB, duration 115.2 seconds).
3.2. Blackbox Audio Reconnaissance (KBR17_blackbox.wav)#
Technical audio parameters:
- Format: Stereo (2 discrete channels).
- Sample Rate: 48,000 Hz.
- Bit Depth: 16-bit Signed Integer (PCM).
- Total Samples: $5,529,608$ samples per channel $\approx$ $115.20$ seconds.
3.3. Nature of the “Ghost Frequency” (1536 Hz vs. Bell 202 AFSK)#
Analyzing the spectrogram and instantaneous frequency across both channels:
- Left Channel:
- Dominated ($95\%$ of duration) by a constant $1536 \text{ Hz}$ sine tone—this is the jamming “Ghost Frequency”.
- Contains 18 intermittent wideband noise bursts spanning 0–4000 Hz.
- Right Channel:
- Active continuously from $0.000\text{s}$ to $111.145\text{s}$.
- Evaluating half-period zero-crossings:
- 20-sample intervals: $f = \frac{48000}{2 \times 20} = \mathbf{1200 \text{ Hz}}$ (Mark tone).
- 11-sample intervals: $f = \frac{48000}{2 \times 11} \approx \mathbf{2200 \text{ Hz}}$ (Space tone).
- $\implies$ The right channel carries standard Bell 202 Audio Frequency Shift Keying (AFSK)!
- Transmission Baud Rate: 1200 baud, yielding: $$\text{Samples per bit} = \frac{48000}{1200} = \mathbf{40 \text{ samples}}$$
3.4. Bell 202 AFSK 1200 Baud Demodulation & UART 8N1 Frame Recovery#
3.4.1. Matched Filter Demodulator#
For each 40-sample window, orthogonal energy projections are calculated:
$$E_{1200} = \left(\sum x[n] \sin(2\pi \cdot 1200 \cdot n / 48000)\right)^2 + \left(\sum x[n] \cos(2\pi \cdot 1200 \cdot n / 48000)\right)^2$$$$E_{2200} = \left(\sum x[n] \sin(2\pi \cdot 2200 \cdot n / 48000)\right)^2 + \left(\sum x[n] \cos(2\pi \cdot 2200 \cdot n / 48000)\right)^2$$- If $E_{1200} > E_{2200} \implies \text{Bit} = 1$ (Mark).
- If $E_{2200} > E_{1200} \implies \text{Bit} = 0$ (Space).
3.4.2. Asynchronous UART 8N1 Framing#
The demodulated bitstream follows standard UART protocol:
- Idle State: High level $1$ (Mark).
- Start Bit: Low level $0$ (Space).
- Data Bits: 8 data bits transmitted LSB-first.
- Stop Bit: High level $1$ (Mark).
Framing yields clean ASCII protocol packets.
3.5. Dissecting NXPKT & Forward Error Correction (RAID-4 / XOR Parity)#
Extracted plaintext lines exhibit the NXPKT structure:
| |
3.5.1. Forward Error Correction (RAID-4 / XOR Parity)#
Session NX-771 comprises 8 data blocks (1024 bytes each), divided into two parity groups:
Group A:
- Members:
SEQ 00,SEQ 01,SEQ 02,SEQ 03, andPARITY A. SEQ 02was lost in transmission.- Recover
SEQ 02via XOR parity reconstruction: $$\text{SEQ 02} = \text{SEQ 00} \oplus \text{SEQ 01} \oplus \text{SEQ 03} \oplus \text{PARITY A}$$
- Members:
Group B:
- Members:
SEQ 04,SEQ 05,SEQ 06,SEQ 07, andPARITY B. SEQ 05was lost in transmission.SEQ 06has two retries (RETRY=1andRETRY=2); selectRETRY=2.- Recover
SEQ 05via XOR parity reconstruction: $$\text{SEQ 05} = \text{SEQ 04} \oplus \text{SEQ 06} \oplus \text{SEQ 07} \oplus \text{PARITY B}$$
- Members:
3.6. Raw DEFLATE Stream Decompression & Flag Extraction#
- Concatenate 8 recovered blocks (
SEQ 00throughSEQ 07) into an $8192 \text{ byte}$ buffer. - Inspecting the first 10 bytes:
0x00 .. 0x07: Header metadata.0x08 .. 0x09: Magic bytes0x02 0x03.0x0A ..: Begins with signature bytesed 98 57 50 53 df be c7 ...$\rightarrow$ Raw DEFLATE Stream (RFC 1951).
- Decompressing via
zlib.decompress(data[10:], -zlib.MAX_WBITS)produces a 10,240-byte TAR archive:NX-771/relay_status.logNX-771/navigation.datNX-771/final_message.txt
- Contents of
NX-771/final_message.txt:1 2 3 4 5 6 7NEXUS EMERGENCY TRANSMISSION KBR-17 // SESSION NX-771 The Severance did not erase every transmission. Some signals survived only because the relay kept redundant fragments. CSSCTF{th3_gh0st_fr3qu3ncy_w4s_n3v3r_s1l3nt}
3.7. Annotated Solution Script (Python)#
| |
3.8. Flag#
| |
4. Echoes of the Relay#
- Category: Forensics
- Challenge: Echoes of the Relay
- File:
relay_backup.img(33,554,432 bytes = 32 MiB) - Flag:
CSSCTF{d3l3t3d_d03snt_m34n_g0n3}
4.1. Challenge Analysis & Investigative Strategy#
“Its recovery lasted exactly 47 seconds. Then it went silent again… an automated recovery system transmitted a damaged storage image from one of its maintenance terminals. Nexus engineers inspected the visible files but found nothing useful. However, the terminal’s final operator apparently tried to preserve something before the system shut down. Recover the operator’s final transmission.”
Key clues mapped to forensic techniques:
| Clue Phrase | Technical Implication |
|---|---|
| “damaged storage image” | Raw disk image, not a plain archive $\rightarrow$ inspect raw filesystem structures |
| “maintenance terminal” | Linux-based host $\rightarrow$ ext4 filesystem |
| “visible files but found nothing useful” | Crucial data resides in unreferenced/unlinked areas (deleted inodes, slack space) |
| “tried to preserve something before shutdown” | Deleted file carving — file was unlinked, but physical blocks remain |
| “final transmission” | Target data represents an operator transmission package or note |
Standard methodology:
- Identify image structure with
file. - Inspect low-level filesystem structures via
debugfsinstead of mounting (mounting only surfaces live files). - Search for deleted inodes (
lsdel) and carve raw allocation blocks. - Analyze secondary data layers (e.g., polyglot data trailing image chunks).
4.2. Step 1: Disk Image Identification#
| |
Output:
| |
The image contains a direct ext4 filesystem with volume label KUIPER_RELAY. No partition table is present; the filesystem starts at offset 0.
4.3. Step 2: Filesystem Metadata Inspection#
| |
Extracted parameters:
| Parameter | Value |
|---|---|
| Volume name | KUIPER_RELAY |
| Filesystem state | clean |
| Block size | 1024 bytes |
| Blocks per group | 8192 |
| Inodes per group | 2048 |
| Inode size | 256 bytes |
| First inode | 11 |
| Journal inode | 8 |
| Inode table (group 0) | blocks 138 – 649 |
| FS created / last write | 2026-09-13 17:17:36 |
| Mount count | 0 (unmounted snapshot) |
Block size = 1024 and Inode size = 256 are vital parameters for computing manual block offsets.
4.4. Step 3: Directory Tree Enumeration#
Using debugfs in read-only mode:
| |
| |
Hierarchy:
| |
Reading system logs:
| |
In /operator/Downloads/diagnostics.txt:
| |
- Forensic Indicator:
Residual filesystem entries detected. While directoryLOST/is completely empty (a distractor), true artifacts remain in unlinked/deleted inodes.
4.5. Step 4: Identifying Deleted Inodes (lsdel)#
| |
| |
One deleted entry exists: Inode 25, size 303 bytes. Examining details:
| |
| |
In ext4, unlinking a file zeroes i_links_count and marks block bitmap entries as free; the underlying data block remains intact until overwritten.
4.6. Step 5: Direct Carving of Residual Data Blocks#
Carving data block 2232 using dd (bs=1024):
| |
Recovered transmission note:
| |
Key intelligence gathered:
archive password = severance2101$\rightarrow$ Password protecting the recovery package.- Target file:
/operator/Pictures/relay_status.png. - “Look beyond what the image viewer shows you” $\rightarrow$ Trailing payload appended after the PNG
IENDchunk.
4.7. Step 6: Extracting PNG Image from Filesystem#
| |
| |
Total file size is 19,834 bytes, noticeably exceeding expected image raster data.
4.8. Step 7: PNG Chunk Structure Analysis#
Parsing chunks via Python:
| |
Output:
| |
There are 560 extraneous bytes trailing the IEND chunk. Examining the signature at offset 0x4b4a:
| |
| |
The data trailing IEND forms a valid ZIP archive starting with magic PK\x03\x04—a classic PNG/ZIP polyglot (appended data).
Carving the embedded ZIP:
| |
4.9. Step 8: ZIP Archive Analysis & Decryption#
| |
| |
The archive uses standard ZipCrypto, allowing direct extraction using unzip -P with the recovered password severance2101:
| |
Output:
| |
4.10. Step 9: Flag Retrieval#
| |
Content of transmission/core_recovery.txt:
| |
4.11. Flag#
| |
4.12. Attack Chain Summary#
| |
4.13. Key Forensic Takeaways#
- Unlinked File $\neq$ Erased Data: An unlinked file in ext3/ext4 releases metadata markers while retaining underlying sector data until allocation reuse occurs.
debugfsvs. Mounting: Low-level inspection utilities expose unreferenced inodes, extent trees, and deleted entries that OS mount routines ignore.- Appended Data Steganography: Trailing bytes appended past standard file terminators (
IENDfor PNG,FFD9for JPEG,%%EOFfor PDF) are routinely used to conceal embedded archives. - Multi-layered Concealment: Forensic artifacts frequently follow sequential tiers (deleted metadata $\rightarrow$ credential note $\rightarrow$ embedded encrypted container $\rightarrow$ final plaintext).
4.14. Quick Command Cheat-Sheet#
| |
4.15. Appendix: Offsets & Reference Values#
| Item | Value |
|---|---|
| Block size | 1024 bytes |
| Inode size | 256 bytes |
| Inode table (Group 0) | Block 138 |
| Inode 25 location | Block 144, offset 0x0000 |
| Inode 25 Extent | ee_block=0, ee_len=1, ee_start=2232 |
| Physical Data Block | Block 2232 (dd bs=1024 skip=2232) |
PNG IEND termination | Offset 0x4b4a (19274) |
| Appended Data Length | 560 bytes |
| Archive Password | severance2101 |
| Flag | CSSCTF{d3l3t3d_d03snt_m34n_g0n3} |
5. Summary & Key Takeaways#
| Metric | The False Timeline | Signal Fracture | Ghost Frequency | Echoes of the Relay |
|---|---|---|---|---|
| Forensic Domain | Linux Artifacts & Timeline Auditing | Raw Disk Carving & Network Reassembly | Audio DSP Demodulation & Parity FEC | Ext4 Inode Carving & Polyglot Analysis |
| Primary Data Source | Auditd (audit.log), Auth log, SQLite metadata.db | Raw MBR Spool Ring Partition + PCAP + Scheduler DB | Stereo WAV Audio (48 kHz PCM) | Linux Ext4 Disk Image (32 MiB) + Deleted Inodes |
| Security Context | Exposing Timestomping & log falsification | Network retry conflict resolution & data integrity | Bell 202 AFSK radio demodulation & noise filtering | Carving unlinked blocks & trailing file steganography |
| Reconstruction / Auth | AES-256-GCM authenticated decryption | SHA-256 integrity catalog verification | XOR Parity Forward Error Correction | Trailing ZIP carving & ZipCrypto password recovery |
Core Technical Lessons:
- Audio Forensics & Covert Channels: High-resolution stereo recordings may embed modulated carrier signals (such as AFSK) within secondary channels. Channel separation and instantaneous frequency profiling are critical for signal characterization.
- Forward Error Correction (FEC): Systems operating over lossy mediums often deploy parity redundancy (such as XOR parity). Recovering lost packets through algebraic reconstruction avoids the need for retransmission.
- Deleted Block Carving & File Polyglots: Operating system file deletions (
unlink) rarely sanitize physical storage sectors. In parallel, evaluating payloads trailing standardized EOF markers remains an essential technique for identifying concealed multi-format containers.
