Skip to main content
This page documents the major design decisions that shape Proone’s architecture and behavior.

​
IPv6 Support

Proone is IPv6-ready with full support across all subsystems.

​
Why IPv6?

The decision to prioritize IPv6 reflects both technical advantages and security assumptions:

Network Oversight

IPv6 is relatively new—network administrators often overlook IPv6 configuration

Load Balancing

IPv6 offers more load-balancing mechanisms like Router Advertisement (RA) and Routing Header (RH)

Performance

Connections with least latency/congestion complete handshake first

Simplicity

Avoids complexity of checking connectivity per IP version

​
Dual-Stack Connection Strategy

When connecting to public DoT servers or Heartbeat hosts:
1

Simultaneous attempts

Proone attempts both IPv4 and IPv6 connections in parallel
2

Race to completion

Whichever connection completes handshake first is initially used
3

IPv6 preference

If both connections establish, IPv4 connection is dropped and IPv6 is used
Minor Issue: If IPv6 handshake takes slightly longer than IPv4, the instance uses IPv4 even though IPv6 would have completed. This edge case is acceptable given the design assumptions.

​
IPv6 Subsystem Support

SubsystemIPv6 Features
ResolvSupports IPv6 public DoT servers, resolves AAAA records
ReconICMPv6-based link-local discovery, IPv6 network targeting
HeartbeatDual-stack connections with IPv6 preference
BNEExploits IPv6 hosts discovered by Recon

​
Design Rationale Summary

Assumptions:
  1. IPv6 configuration often neglected, creating security gaps
  2. Connections with optimal network conditions complete faster
  3. IPv6 infrastructure provides better redundancy
Trade-offs:
  • Accepts minor timing edge cases for simplicity
  • Skips explicit connectivity checks (uses getsockname()/gethostinfo())
  • Favors IPv6 even when IPv4 might be more stable

​
Running Lean

Proone is designed to minimize resource consumption on embedded devices.

​
Philosophy

Core Principle: Honoring other processes on the system decreases the chance of detection by system administrators.
This philosophy manifests in several design choices:

​
Single-Threaded Cooperative Multitasking

Proone uses GNU Pth (Pthsem library) for cooperative multitasking: Benefits:
  • Restricts CPU usage to one logical thread
  • Minimal context switching overhead
  • Predictable resource consumption
  • No race conditions or locking complexity
Rationale: 
Target: Resource-scarce embedded devices (most are single-core)
Strategy: Many infected low-powered devices > Few infected high-performance systems
This may seem like a missed opportunity on multi-core systems, but most vulnerable IoT devices are single-core anyway. The strategy prioritizes breadth over power.

​
Compartmentalized Design

Proone’s architecture is resilient to syscall failures, particularly ENOMEM:

Partial Initialization

Can run with subset of workers if some fail to start

Graceful Degradation

Reduced functionality is better than total failure

No Retries

Assumes resources remain scarce—retrying is futile

Independent Subsystems

Workers don’t depend on each other for initialization

​
Example Scenarios

Scenario 1: No Heartbeat Worker 
✓ Recon: Running - discovers vulnerable hosts
✓ BNE: Running - compromises discovered hosts
✓ Resolv: Running - available but unused
✗ Heartbeat: Failed - cannot respond to C&C TXT REC

Result: Instance continues infecting network but cannot receive commands
Scenario 2: No Recon Worker 
✓ Heartbeat: Running - responds to C&C commands
✓ BNE: Running - awaits targets from Recon
✓ Resolv: Running - supports Heartbeat TXT REC queries
✗ Recon: Failed - no new targets discovered

Result: Instance serves backdoor and responds to C&C but cannot spread

​
BNE Worker Pool Management

The BNE worker pool exemplifies “running lean”:
  • Maximum 128 workers - Arbitrary limit rarely reached in practice
  • Lowest priority - Prevents starvation of vital workers
  • Graceful ENOMEM - Stops spawning when memory exhausted
  • No cleanup attempts - Accepts current state when resources depleted
1

Normal operation

BNE workers spawn as Recon discovers targets
2

Memory pressure

System approaches memory limit
3

ENOMEM failure

New BNE spawn attempts fail with ENOMEM
4

Continued operation

Existing workers complete; no new workers spawn; other subsystems unaffected

​
Resource Conservation Techniques

TechniqueImplementationBenefit
Connection poolingResolv keeps DoT connections openReduces handshake overhead
Minimal dependenciesOnly essential libraries (libssh2, mbedtls, zlib, pthsem)Smaller binary size
Data maskingDVault XORs sensitive dataSecurity without crypto overhead
Single-stream BACompressed executables in one streamMaximizes compression ratio

​
Ephemeral Presence

Proone makes no attempt to seek permanent residency on infected devices.

​
Rationale

This design choice serves multiple security and operational goals:

Hard to Capture

Makes executable difficult to retrieve from infected device

No Forensic Trace

Memory-backed filesystems leave no traces after power cycle

Device Protection

Avoids filling small flash storage on IoT devices

Operational Security

Reduces detection surface for incident responders

​
Mirai Comparison

Both Mirai and Proone delete executables immediately after process starts: Mirai Approach:
  • Deletes executable after startup
  • Uses any read-writable mount point for upload
  • Still capturable from filesystem before deletion
  • Can be dumped from memory with development tools
Proone Enhancement:
  • Deletes executable after startup (same as Mirai)
  • Only uses tmpfs and devtmpfs mount points (memory-backed)
  • Eliminates traces on non-volatile storage
  • Still dumpable from memory, but requires development tools

​
Memory-Backed Filesystem Strategy

1

Target identification

BNE worker identifies only tmpfs and devtmpfs mount points
2

Upload to RAM

Executable uploaded to memory-backed filesystem
3

Execution

Binary executed from tmpfs/devtmpfs
4

Self-deletion

Process deletes executable immediately after startup
5

Power cycle

Reboot erases all traces—no forensic evidence on disk
Important: While the executable can still be captured through core dumps or memory inspection, this requires:
  • Development tools on the device
  • Kernel support for core dumps
  • Technical expertise
Ordinary embedded devices lack these capabilities, making capture nearly impossible in the wild.

​
Storage Considerations

Why Memory-Backed Filesystems? Typical embedded device profile:
  • Small SPI flash memory (often < 16MB)
  • Relatively larger RAM (32MB-128MB common)
  • Proone binary is large (carries executables for multiple architectures)
Traditional Approach:
  Flash: [██████████] 100% Full - Upload fails
  RAM:   [███░░░░░░░]  30% Used

Proone Approach:
  Flash: [██████░░░░]  60% Used - Never touched
  RAM:   [██████░░░░]  60% Used - Temporary executable

​
Capture Difficulty Comparison

ScenarioMiraiProone
Before executionRetrievable from filesystemRetrievable from tmpfs
After executionDeleted, memory dump neededDeleted, memory dump needed
After rebootMay persist in flashCompletely erased
Forensic analysisDisk forensics possibleNo disk traces
Capture difficultyHardVery hard
Historical Context: It would have been nearly impossible to capture the Mirai executable running in the wild due to the self-deletion technique. Proone takes this further by ensuring even the upload location leaves no persistent traces.

​
Security vs. Persistence Trade-off

Advantages:
  • Extremely difficult to analyze
  • No forensic footprint after power cycle
  • Fits better in RAM than flash on IoT devices
  • Network administrators cannot easily obtain samples
Disadvantages:
  • No persistence—reboot cleans infection
  • Must re-infect devices after power cycles
  • Relies on continuous reinfection through network scanning
The trade-off favors operational security over persistence. The design assumes that maintaining low detectability is more valuable than surviving reboots, especially given Proone’s autonomous spreading capability.

​
Additional Design Principles

​
Wide Device Compatibility

Proone targets the broadest possible range of Linux devices:
1

Old POSIX standards

Coded to _POSIX_C_SOURCE=200112L standard for compatibility with old Linux 2.6.x kernels
2

No filesystem assumptions

Doesn’t assume /proc, /sys, or /dev are available (can be disabled on embedded Linux)
3

Kernel configuration agnostic

Works across diverse kernel configurations found on IoT devices
4

Graceful feature degradation

Silently disables features when APIs return ENOSYS
The _POSIX_C_SOURCE=200112L macro doesn’t prevent use of newer APIs—it only provides hints. Code may compile but fail at runtime with ENOSYS on old kernels if newer syscalls are used.

​
Minimal Dependencies

Dependencies kept to absolute necessities: Runtime Dependencies:
  • libssh2 - SSH brute force vector
  • mbedtls - TLS connections (DoT, Heartbeat protocol)
  • zlib - Binary archive compression
  • pthsem - Cooperative multitasking
Build-Only Dependencies:
  • libyaml - Configuration file parsing (hostinfod)
  • mariadb-connector-c - Database backend (hostinfod)
All libraries compiled with default configurations to minimize build complexity and maintain consistency across platforms.

​
Design Philosophy Summary

IPv6-First

Leverage overlooked IPv6 configurations and modern network features

Resource-Conscious

Minimize footprint to avoid detection and honor system resources

Ephemeral

No persistence—prioritize operational security over survival

Compartmentalized

Independent subsystems allow graceful degradation

Compatible

Support widest range of Linux devices and kernel configurations

Minimal

Only essential dependencies and features

​
Next Steps

Binary Architecture

Learn about Binary Archive, DVault, and binary recombination

Build docs developers (and LLMs) love

Get started for freeTalk to us