DEV Community: rvbbit

Rvbbit Ghost: Can VPNs, Tor, and Disposable VMs Really Protect Your Identity?

rvbbit — Thu, 15 Oct 2026 21:09:15 +0000

What if your IP address is hidden, your traffic is routed through multiple privacy layers, and your virtual machine disappears after every session — but you can still be identified?

This question is more complicated than it appears.

In cybersecurity, we spend considerable time studying how attackers compromise systems, establish persistence, manipulate network traffic, and extract sensitive information. Yet another question deserves equal attention:

How much information can an observer collect about a researcher operating inside a supposedly isolated environment?

A VPN can change the network address visible to an external service. Tor can distribute trust across multiple relays. Virtual machines can establish useful isolation boundaries. Disposable environments can reduce persistent application data.

But none of these mechanisms automatically makes an operator anonymous.

A compromised host can observe its guests. Network traffic may reveal timing patterns. Browser activity can disclose identity. A single authenticated account can defeat several layers of network privacy.

I wanted to examine these problems through practical security engineering rather than theoretical promises.

That research led me to develop Rvbbit Ghost.

GitHub: https://github.com/buter-chkalova/rvbbit-ghost

Rvbbit Ghost is an experimental Windows-based orchestration system for disposable Whonix research sessions. It combines VirtualBox isolation, signed-image verification, an OpenVPN-before-Tor architecture, session lifecycle management, and security validation.

It is not an invisibility tool, an exploitation framework, or a guarantee of anonymity.

Its purpose is to explore a narrower and more useful question:

Can we make sensitive, authorized research sessions more isolated, more repeatable, and less likely to expose persistent data — without pretending that the underlying operating system has become trustworthy by magic?

1. The Real Problem: Anonymity Is Not a Single Security Property

When people discuss online anonymity, they frequently reduce the problem to one measurement:

What IP address does the destination see?

That is only one part of the attack surface.

Consider a research environment in which the public IP address has been successfully concealed.

An observer might still identify or correlate an operator through:

Browser fingerprinting and application characteristics.
Authenticated accounts and reused identifiers.
Traffic timing, duration, and volume.
Endpoint telemetry and host-level execution records.
Files downloaded from a protected environment and opened elsewhere.
Metadata exposed through documents or communications.
Compromised operating systems, hypervisors, or browser processes.
Behavioral patterns connecting multiple supposedly independent sessions.

Anonymity, privacy, and isolation overlap, but they are not interchangeable.

Network privacy concerns what network observers can learn.

Identity separation concerns whether different activities can be connected to the same person.

Execution isolation concerns whether activity inside one environment can affect another.

Data disposability concerns what application state persists after the environment has been destroyed.

A system can improve one of these properties while providing relatively little protection for the others.

This distinction became the foundation of Rvbbit Ghost.

Figure 1. Rvbbit Ghost architecture and security boundaries.

2. Architecture: Windows → Whonix → OpenVPN → Tor

The project uses Windows 10/11 as the host operating system, VirtualBox as the virtualization layer, and Whonix as the guest environment.

The intended traffic path is:

Whonix-Workstation
        |
        | Internal VirtualBox network
        v
Whonix-Gateway
        |
        | OpenVPN tunnel
        v
     VPN provider
        |
        | Tor connection
        v
     Tor network
        |
        v
     Internet

The ordering matters.

Whonix-Workstation does not receive a direct VirtualBox NAT adapter. Its only network interface connects to a session-specific internal network shared with Whonix-Gateway.

The Gateway handles external connectivity and is configured to establish OpenVPN before Tor.

This means Workstation is not intended to have an independent route to the Internet.

Why separate Workstation and Gateway?

A single operating system handling browsing, applications, network routing, and privacy enforcement combines several responsibilities within one environment.

Separating these components provides a clearer security boundary.

Whonix-Workstation contains the browser session.

Whonix-Gateway handles the network routing.

VirtualBox controls the guest networking configuration.

The Windows launcher manages installation, verification, session creation, readiness checks, and cleanup.

This does not mean the Gateway is invulnerable. A sufficiently capable attacker compromising the Gateway or the underlying host may undermine the intended routing restrictions.

But separation creates a structure in which specific assumptions can be identified and tested.

That is a meaningful engineering advantage.

3. Why Put a VPN Before Tor?

This is one of the more interesting architectural decisions.

Tor already provides network anonymity properties through its relay architecture. Adding a VPN does not automatically make Tor more anonymous.

Instead, it changes the distribution of information among observers.

In the VPN-before-Tor configuration:

The ISP can observe:

The subscriber's Internet connection.
The VPN endpoint.
Connection timing, duration, and traffic volume.

The VPN provider can observe:

The subscriber's source IP address.
Connections from its infrastructure toward the Tor network.
Traffic timing and volume.

The Tor entry relay typically observes:

The VPN exit address rather than the subscriber's home address.

The destination website observes:

The Tor exit address.
Browser characteristics and data voluntarily submitted to the service.

In an uncompromised configuration, the destination should not directly learn the operator's home IP address through ordinary network routing.

However, an important limitation remains:

The VPN provider becomes another party capable of observing and potentially correlating network metadata.

If an adversary can observe multiple points across the path, timing analysis may remain possible.

This is why I do not describe VPN-before-Tor as a universal improvement over Tor alone.

Its value depends on the threat model.

For one scenario, concealing direct public Tor connections from the ISP may be useful. For another, adding a VPN provider may introduce an unnecessary dependency.

The important question is not how many layers exist.

It is which observer each layer is intended to constrain.

4. Fail-Closed Networking: A Security Boundary Must Survive Failure

Security controls are relatively easy to describe when every component works correctly.

The more interesting question is what happens when a dependency fails.

Suppose a VPN connection unexpectedly terminates.

Does Tor continue through the host's ordinary network route?

Does the Workstation retain connectivity?

Does the user receive a warning, or does the environment silently continue operating under different assumptions?

Rvbbit Ghost requires a fail-closed configuration in Whonix-Gateway.

The operator must configure the appropriate tunnel firewall and verify that connectivity fails when OpenVPN is stopped.

The intended behavior is straightforward:

VPN active
    |
    v
Tor permitted
    |
    v
Workstation connectivity permitted


VPN unavailable
    |
    v
Tor egress blocked
    |
    v
Workstation Internet connectivity fails

This protects against a category of configuration failures in which traffic could otherwise follow an unintended route.

There is an important implementation detail.

The Windows launcher does not independently inspect and cryptographically prove the state of the VPN tunnel inside the guest.

Instead, it requires a fresh operator-confirmed readiness check before starting Workstation.

This is operator attestation, not automatic verification of the tunnel by the host.

That limitation is documented deliberately.

Adding a host-to-guest monitoring mechanism could provide additional automation, but it would also create another integration channel between the Windows host and the isolated guest.

In security engineering, improving observability can sometimes weaken isolation.

That trade-off deserves explicit consideration.

5. Reducing the Host–Guest Attack Surface

Virtualization is frequently treated as if creating a VM automatically produces a strong security boundary.

In reality, virtualization environments provide numerous integration mechanisms designed for convenience.

Some are useful in everyday computing but undesirable in sensitive research environments.

Rvbbit Ghost disables several VirtualBox integration features, including:

Shared clipboard and clipboard file transfer.
Drag and drop.
Shared folders.
USB integration.
Audio integration.
VirtualBox remote display.
VirtualBox recording.

Why?

Because every integration point can become a channel through which information crosses the host–guest boundary.

A shared clipboard can accidentally transfer sensitive material between environments.

A shared folder can expose host files to guest software.

External device access can increase the complexity of the isolation boundary.

Disabling these features does not eliminate hypervisor vulnerabilities or prevent a compromised Windows administrator from observing the guest.

It does reduce unnecessary interaction between the two environments.

The principle is simple:

Do not create a cross-boundary capability unless the workflow actually requires it.

This is the same philosophy used in reducing attack surfaces across operating systems, container environments, and enterprise networks.

6. Disposable Virtual Machines: Reducing Persistent State

Persistence is central to both offensive and defensive cybersecurity.

Attackers seek persistence to maintain access.

Defenders examine persistent artifacts to understand how an intrusion occurred.

Privacy engineering introduces a different question:

What application data should remain after a legitimate research session ends?

Rvbbit Ghost uses disposable linked clones derived from clean Whonix snapshots.

The lifecycle follows this model:

Verified Whonix appliance
          |
          v
     Imported base
          |
          v
     Clean snapshot
          |
          v
   Disposable VM pair
          |
          v
     Research session
          |
          v
       Shutdown
          |
          v
    Validated cleanup

Each session creates a temporary Gateway and Workstation pair with session-specific identities and networking.

During normal shutdown, the session VMs and their associated differencing disks are removed.

The goal is to avoid carrying browser cookies, browsing history, cache, local storage, and other session-specific state into the next research session.

This reduces the risk of accidental cross-session contamination.

But it is essential to distinguish logical disposal from secure physical erasure.

Deleting a virtual disk does not prove that every underlying storage block has been overwritten or rendered unrecoverable.

Windows filesystem journals, page files, backups, crash dumps, SSD behavior, and other storage mechanisms may preserve artifacts beyond the lifecycle of a VM.

Likewise, the clean base images and project maintenance state persist by design.

Rvbbit Ghost therefore makes a limited, defensible claim:

It reduces persistent browser-session state.

It does not guarantee forensic-proof deletion.

7. Supply-Chain Security: Isolation Begins Before the First Boot

A disposable environment is not trustworthy merely because it is temporary.

If the original VM image has been modified maliciously, every disposable clone may inherit the compromise.

For this reason, Rvbbit Ghost includes supply-chain verification during installation.

The project downloads a pinned Whonix appliance from the official source and verifies its OpenPGP signature using GnuPG and a pinned upstream signing-key fingerprint.

The purpose is to reduce the risk of importing an unauthorized or modified base image.

The trust chain still depends on components such as the Windows host, Gpg4win, package installation mechanisms, firmware, and the verified upstream software.

Cryptographic signature verification does not eliminate these dependencies.

It makes one important part of the supply-chain boundary more explicit and testable.

For me, this is a central lesson:

Security architecture must account for how trusted components enter the system, not only how those components behave after installation.

8. What Could an Attacker Still Do?

This is where the project becomes particularly interesting from an offensive-security and threat-modeling perspective.

Rather than asking whether the architecture is anonymous, we can examine hypothetical attack scenarios and identify which defensive assumptions they challenge.

Scenario A: Network Traffic Correlation

Imagine a sophisticated adversary capable of observing traffic at multiple points across a network.

The adversary cannot necessarily decrypt Tor traffic, but may observe connection timing and traffic volume.

If activity entering one part of a system can be correlated with activity leaving another, traffic analysis may reveal relationships that encryption alone does not hide.

Rvbbit Ghost does not eliminate this class of attack.

OpenVPN-before-Tor changes the directly observable source address at the Tor entry point, but it does not make timing correlations mathematically impossible.

Security lesson: Encryption protects content, but metadata remains an important part of the attack surface.

Scenario B: Browser-Based Identification

Suppose a website collects browser characteristics and observes user activity.

Tor Browser is designed to reduce fingerprinting and make users harder to distinguish.

However, unusual configuration changes, additional extensions, disclosed personal information, and authenticated identities can undermine those protections.

Rvbbit Ghost intentionally relies on the standard Tor Browser rather than attempting to create a heavily customized browser fingerprint.

This is an important distinction.

Making a browser appear technically unusual can sometimes make it more identifiable, not less.

Security lesson: Anonymity sets are often more valuable than arbitrary customization.

Scenario C: Host Compromise

Consider a Windows computer already compromised by malware with sufficient privileges.

The malicious software may potentially observe processes, keystrokes, screen content, storage activity, or information accessible through the hypervisor.

Network routing inside Whonix does not prevent a compromised host from observing data before it is encrypted or after it is decrypted inside the guest.

The attacker may not need to defeat Tor at all.

This is a fundamental limitation.

A sufficiently privileged malicious host cannot be made harmless by placing an application inside VirtualBox.

Security lesson: A privacy boundary cannot be stronger than the trusted infrastructure enforcing it against an adversary that controls that infrastructure.

Scenario D: Malicious Downloaded Content

Imagine a researcher downloading a document from an untrusted website during an authorized investigation.

Inside the isolated environment, the document remains subject to the protections and vulnerabilities of the guest.

If the researcher exports the document and opens it directly on the Windows host, the original security boundary no longer applies to that execution.

A malicious document may exploit the application used to open it, and an external application may initiate its own network activity.

The VPN/Tor routing policy for Whonix-Workstation does not automatically protect arbitrary Windows applications.

Security lesson: Isolation is a property of an execution environment, not a permanent property of a downloaded file.

Scenario E: Identity Correlation Across Sessions

A researcher creates two disposable virtual machines on different days.

Both sessions use Tor.

Both VMs are subsequently deleted.

Are they necessarily unlinkable?

No.

If both sessions authenticate to the same account, reuse identifying information, or produce uniquely recognizable content, they may be linked independently of the network path.

Deleting cookies does not erase information already collected by remote services.

The system can create fresh application state, but it cannot guarantee that a human operator will behave as an unrelated identity.

Security lesson: Operational security is not something that infrastructure can fully automate.

Scenario F: Virtualization and Escape Vulnerabilities

A vulnerability in a browser, guest operating system, virtualization component, or host driver can potentially undermine the assumed separation.

Disabling integrations reduces exposure, but it is not a proof that VM escape or host compromise is impossible.

Rvbbit Ghost does not claim protection against unknown hypervisor vulnerabilities or malicious firmware.

These threats remain outside its assurance boundary.

Security lesson: Reducing available attack paths is valuable even when eliminating every possible path is unrealistic.

9. What Remains Visible After the Session?

One of the most important decisions in this project was not to disable Windows security logging.

Rvbbit Ghost does not erase Windows Event Logs, disable Defender, manipulate audit records, or falsify execution history.

That is intentional.

A host operating system can generate many types of evidence associated with virtual-machine execution.

For example:

Process execution and PowerShell activity.
VirtualBox configuration and diagnostic records.
Security-product telemetry.
Network connection metadata.
Filesystem activity and storage artifacts.

Disabling selected logging features does not guarantee that execution becomes unobservable.

Other components may continue recording information.

Moreover, selectively manipulating forensic records can weaken incident response and undermine legitimate investigations.

My objective was not to turn Windows into an anti-forensic platform.

It was to isolate the browser session and reduce unnecessary persistence within the project-controlled environment.

This distinction matters professionally.

Privacy engineering and anti-forensic manipulation are not the same discipline.

A responsible research environment should have an explicit data-retention model and documented limitations rather than making unsupported claims about disappearing without a trace.

10. Engineering Reliability Is Part of the Security Model

Many security tools focus heavily on the initial configuration while paying less attention to what happens after an unexpected interruption.

But real systems crash.

Power can fail.

Processes may terminate halfway through cleanup.

A VM may be deleted successfully while another remains registered.

Rvbbit Ghost addresses these lifecycle problems through several engineering mechanisms.

Validated resource cleanup

Project-specific VM names and recorded UUIDs are checked before destructive cleanup operations.

The objective is to avoid accidentally deleting unrelated VirtualBox machines.

Cross-process locking

Installation, startup, maintenance, auditing, and cleanup operations require coordinated access to project state.

A cross-process lock reduces the risk of conflicting state changes.

Atomic state persistence

The project uses atomic state replacement and schema migration to make stored lifecycle information more resilient.

Interrupted-session recovery

If a session is interrupted, the project can identify registered session resources and attempt validated recovery and cleanup.

Clean-base maintenance

Updated clean snapshots can be created after controlled maintenance and renewed VPN checks.

These mechanisms may be less visually impressive than encryption or traffic routing, but they are important.

A security control that works only when every operation completes perfectly is not a particularly reliable control.

Failure handling is part of the security architecture.

11. Validation: What Has Actually Been Tested?

I think security research should distinguish implementation, automated validation, and real-world assurance.

The repository includes a PowerShell validation suite covering important properties such as:

PowerShell syntax and configuration checks.
Pinned release metadata and expected download origins.
Network isolation invariants.
Invalid signature rejection.
State migration and atomic persistence.
Lock contention.
Audit failure behavior.
Partial cleanup and recovery handling.

These checks provide useful confidence in specific parts of the implementation.

However, the project remains an experimental research prototype.

Static and mocked behavior checks do not prove that the full environment will work correctly across every combination of Windows, VirtualBox, Whonix, and VPN provider versions.

Full end-to-end validation requires a properly configured Windows test host.

I do not consider this a minor distinction.

There is a substantial difference between saying:

“The project contains tests for critical security invariants.”

And saying:

“The complete system has been independently proven secure.”

The first is an engineering statement.

The second would require a much stronger body of evidence.

12. Where Could This Research Go Next?

Rvbbit Ghost also provides a foundation for investigating improvements to isolated research environments.

Several areas are particularly interesting.

More systematic adversarial testing

A useful next step would be a reproducible laboratory test matrix covering network failures, unexpected shutdowns, isolation misconfigurations, and recovery behavior.

Instead of relying solely on successful startup scenarios, the objective would be to deliberately test where assumptions break.

For example, a controlled experiment could measure whether connectivity is consistently blocked under different VPN failure conditions.

The test results should be recorded and compared against the architecture's intended invariants.

Stronger readiness verification

Operator-confirmed VPN checks are an acknowledged limitation.

Research could explore how to verify guest networking state more reliably without creating excessive host-to-guest trust or integration.

The difficult part is not merely collecting another status value.

It is establishing whether that status provides trustworthy evidence of the actual routing behavior.

Formalized session lifecycle testing

Disposable environments benefit from precise state models.

Installation, initialization, launch, execution, shutdown, recovery, and removal can be treated as explicit states with permitted transitions.

Future testing could focus on whether unexpected transitions leave behind resources or violate isolation assumptions.

Comparative host security

Windows with a hosted hypervisor is a practical environment for experimentation.

It is not the strongest possible architecture for every threat model.

Comparing Windows-hosted Whonix with Linux-based configurations and Qubes-Whonix could help identify where architectural changes provide greater security value than additional scripts.

Privacy and forensic artifact measurement

Another useful research direction would be to compare what remains after normal VM shutdown across different storage and host configurations.

This could include project-controlled data, retained maintenance state, VirtualBox artifacts, and relevant host telemetry.

The objective should be accurate measurement, not concealment or destruction of legitimate audit evidence.

A careful study could distinguish between data that is removed from ordinary application use and data that may remain accessible through forensic examination.

13. Where Rvbbit Ghost Fits Into Offensive Security

Offensive security is not limited to exploiting vulnerable applications.

It also involves understanding operating-system behavior, trust relationships, attack surfaces, network protocols, and the assumptions that make an attack possible.

Rvbbit Ghost approaches these subjects from the environment-design perspective.

For an authorized researcher, it provides an experimental platform for studying:

Network isolation and routing dependencies.
Trust boundaries between host and guest systems.
Operational security and identity correlation.
Data persistence and disposal.
Supply-chain validation.
Security control failures and recovery.
The limits of layered privacy architectures.

It does not include an exploitation framework, credential theft functionality, persistence payloads, or mechanisms for bypassing customer attribution requirements.

That separation is deliberate.

Professional penetration testing operates within written authorization and rules of engagement.

Some engagements require declared source IP addresses, comprehensive audit logs, or specific network routes. In those situations, Tor and consumer VPN infrastructure may be inappropriate.

A privacy-oriented research environment should never override the customer's security requirements.

Understanding when not to use a tool is part of using that tool professionally.

14. The Most Important Lesson: More Layers Do Not Automatically Mean More Security

It is tempting to describe a chain containing Windows, virtualization, a VPN, Whonix, and Tor as inherently secure because it contains multiple technologies.

But security is not simply the number of layers between an operator and a destination.

Each layer introduces assumptions.

Windows must remain trustworthy enough to host the environment.

VirtualBox must enforce its intended boundaries.

The Whonix images must be authentic.

The VPN must behave according to the configured policy.

Tor and the browser must operate within their expected threat models.

The operator must avoid revealing identity through unrelated channels.

Some layers mitigate specific exposures. Others introduce new dependencies.

The correct engineering question is therefore not:

How can I add another privacy layer?

It is:

What exact failure or adversary does this layer protect against, how can I verify that protection, and what new risks does it introduce?

That question should guide the evolution of the project.

Final Thoughts

Rvbbit Ghost is not an attempt to create a machine that cannot be observed.

It is an attempt to explore how far isolation, disposable execution, explicit routing requirements, and disciplined lifecycle management can go on a conventional Windows host.

The project reflects an approach to cybersecurity that I consider increasingly important:

Understand the attacker. Model the trust boundaries. Test the failure conditions. Build defensive controls. Document what those controls cannot do.

A VPN does not make identity disappear.

Tor does not protect against every compromised endpoint.

Virtualization does not eliminate the underlying host from the trusted computing base.

Deleting a VM does not erase every trace of execution.

And a sophisticated architecture does not compensate for poor operational security.

But none of that makes isolation, privacy controls, or disposable environments meaningless.

It makes precise threat modeling more important.

The goal is not perfect invisibility.

The goal is to understand exposure, reduce unnecessary risk, and build systems whose security properties can be explained and tested.

Security begins where assumptions are challenged — not where promises are made.

Explore the Project

Rvbbit Ghost — Experimental Whonix Session Orchestration

GitHub: https://github.com/buter-chkalova/rvbbit-ghost

Additional technical documentation:

Rvbbit Ghost is an experimental, open-source research prototype intended for authorized security assessments, privacy research, and controlled laboratory environments. It does not guarantee anonymity or protect against every adversary.

Author: rvbbit
GitHub: buter-chkalova

RVBBIT: What I Learned Building a Linux Kernel Rootkit PoC — and Why I Ended Up Studying Detection

rvbbit — Sun, 09 Aug 2026 14:58:07 +0000

I didn't start RVBBIT with the idea of building a security framework.

It was much simpler than that.

I wanted to understand Linux rootkits beyond reading about them.

I had been studying techniques such as syscall hooking, DKOM, process hiding and kernel module hiding separately, and at some point I realized that reading another explanation wasn't going to answer the questions I had.

I wanted to see what happened when these techniques actually lived together.

So I started writing RVBBIT.

The first version was an educational Linux kernel rootkit PoC. The techniques themselves were not new, and I don't want to pretend otherwise. Most of them have been documented and discussed for years.

What made the project interesting to me was putting several of them into one implementation and watching where they interacted, where they broke, and what they failed to hide.

That last part eventually changed the direction of the project completely.

Project RVBBIT:
https://github.com/buter-chkalova/project-rvbbit

It started with hiding things

The original goal was fairly straightforward: take several established Linux rootkit techniques and understand them by implementing them.

RVBBIT ended up covering experiments around:

process hiding and DKOM;
kernel module hiding;
syscall interception;
filesystem visibility;
TCP connection visibility;
selected interference with eBPF-related mechanisms;
persistence.

At first, I was looking at each feature mostly from the offensive side.

Can a process disappear from a normal enumeration path?

Can a loaded module disappear from the view an administrator normally expects?

Can directory entries be filtered before userspace sees them?

Can the representation of a TCP connection be changed without removing the connection itself?

Those are useful implementation questions, but after working on the project for a while I noticed that they all had something in common.

I wasn't really removing things.

I was changing how they were observed.

That sounds obvious when written down. It wasn't as obvious to me when I started.

A hidden process is still a process

Take process hiding.

A running process has kernel state associated with it. Userspace tools don't somehow inspect the physical reality of the machine and discover processes independently. They ask the operating system for information.

Normally we can think about it roughly like this:

kernel state
     |
     v
kernel interface
     |
     v
userspace

If code inside the kernel interferes with that path, the result changes:

actual state
     |
     v
modified observation path
     |
     v
reported state

The process may still be executing.

The interesting part is that one observer no longer reports it.

This distinction started appearing everywhere in RVBBIT.

With DKOM-style manipulation, the object can continue to exist while a relationship used to enumerate it has changed.

With file hiding, the file doesn't necessarily stop existing. A directory listing can simply stop reporting its entry.

With network hiding, the connection can remain active while one representation of network state no longer shows it.

So I gradually stopped thinking in terms of:

"How do I hide X?"

and started thinking:

"Which view of X am I actually changing?"

That turned out to be a much better question.

The techniques aren't new. Combining them was the useful part.

This is something I want to be explicit about.

RVBBIT does not contain some previously unknown Linux rootkit primitive.

DKOM isn't new.

Syscall interception isn't new.

Module hiding isn't new.

Neither is filtering filesystem or network information.

But studying these things separately can make them look cleaner than they really are.

Once several mechanisms exist inside the same project, you start running into relationships between them.

A concealment mechanism may affect one observation path and leave another untouched.

A persistence mechanism creates artifacts outside the kernel.

A method that works on one kernel version may depend on assumptions that disappear on another.

Two security tools may look independent while actually receiving information through the same kernel mechanism.

Those interactions became more interesting to me than adding another hiding feature.

Interestingly, this was also one of the things other researchers noticed about RVBBIT.

In April 2026, the Spanish cybersecurity publication Hackplayers published a technical analysis of the project:

RVBBIT: anatomía de un rootkit LKM moderno basado en stealth, DKOM y anti-eBPF

https://www.hackplayers.com/2026/04/rvbbit-anatomia-de-un-rootkit-lkm.html

They went through several parts of the implementation, including DKOM, syscall interception, hiding mechanisms and the project's interaction with eBPF-related observability.

What I appreciated about their analysis was that they didn't present RVBBIT as a completely new rootkit technique. They looked at it as a case study that brought a number of existing ideas together.

That's much closer to how I see the project myself.

Later, the project also appeared in a Chinese technical article on CSDN:

内核里的“幽灵”：一套Linux Rootkit隐身术完全拆解

https://blog.csdn.net/chen1415886044/article/details/161462914

Seeing other people independently take the code apart was probably more useful than getting another GitHub star. It showed me which parts of the project were understandable from the outside and which ideas attracted attention without me explaining them first.

Syscall hooking gave me a different kind of question

Syscall interception is a good example of how my thinking changed.

From the offensive side, the idea is familiar.

Very roughly:

userspace
    |
    v
system call
    |
    v
sys_call_table
    |
    v
kernel handler

Change the relevant mapping and you can redirect execution.

When I first worked with this, I was interested mainly in the interception itself.

Later I realized the defensive question was almost sitting next to it:

If I expect a syscall entry to point somewhere, and it suddenly points somewhere else, can I verify that?

That sounds like a small change in perspective, but it changes the problem.

Instead of trying to recognize every possible behavior produced by a hook, you can start asking questions about integrity.

What was the expected target?

What is the current target?

Where does my expected value come from?

And, more importantly: why should I trust that source?

The last question is where things become difficult.

A detector inside a compromised kernel is still inside a compromised kernel.

`/proc` taught me not to confuse tools with independent observers

Another thing that became obvious while working on visibility was that running two different commands does not necessarily give you two independent observations.

Imagine two tools receiving their information through the same modified kernel path:

             kernel state
                  |
             modified path
                  |
          +-------+-------+
          |               |
        tool A           tool B

Both tools agree.

And both can still be wrong.

This matters when thinking about rootkit detection because "I'll compare what two tools report" only helps if those tools ultimately depend on sufficiently independent sources.

If both trust the same compromised representation, agreement doesn't tell us much.

This became one of the ideas I wanted to explore further.

eBPF made the observability problem even more interesting

I also became interested in eBPF because modern Linux security tooling doesn't have to rely entirely on periodic enumeration.

It can observe events much closer to where they occur.

That changes the problem for a traditional rootkit.

RVBBIT contains experiments involving selected BPF-related operations, but I don't consider this some universal "anti-eBPF" mechanism. Real eBPF-based security systems are considerably more complicated than that.

The useful lesson was different.

Imagine a security system stops receiving the telemetry it expects.

Does that mean nothing happened?

Or does it mean something interfered with the observer?

Those two states look similar from the perspective of an empty event stream, but from a security perspective they are completely different.

At that point I started thinking about the observer itself as something whose integrity matters.

That idea later carried over into RVBBIT Arsenal.

At some point I stopped wanting more rootkit features

There was a point where I could have continued adding things to RVBBIT.

Another hiding mechanism. Another hook. Another persistence experiment.

But I wasn't sure that would make the project more useful.

The question I kept coming back to was:

If I know exactly how I hid something, where should I look for the evidence I failed to remove?

That became the reason for starting the second project.

RVBBIT Arsenal:
https://github.com/buter-chkalova/rvbbit-arsenal

Arsenal separates the work into offensive and defensive sides:

I initially thought about this as "attack versus defense."

I don't anymore.

The model I find more useful now is:

technique
   |
   v
state modification
   |
   v
visibility change
   |
   v
something remains observable
   |
   v
detection idea
   |
   v
limitations

The last step matters just as much as the others.

RvbbitSafe isn't an "anti-rootkit"

The defensive part of Arsenal is called RvbbitSafe.

An earlier version of the project used much stronger language around the defensive side. Looking back, I don't think that was technically justified.

RvbbitSafe isn't a universal Linux anti-rootkit, and I don't present it as one now.

It's a research prototype built around a simpler idea:

if one representation of system state has been manipulated, can another representation expose the difference?

Process visibility is a good example.

Imagine two ways of reasoning about whether the same process exists:

              process
                 |
        +--------+--------+
        |                 |
        v                 v
     view A             view B
        |                 |
        +--------+--------+
                 |
              compare

Normally, we expect the views to agree.

If I deliberately alter the state used by one of them and the other remains intact, the disagreement can become a detection signal.

This is generally described as a cross-view approach.

But while implementing it, another problem becomes obvious.

How independent are those views really?

If an attacker modifies both of them, the detector can lose the discrepancy.

If they share some lower-level dependency that has already been corrupted, they may agree for the wrong reason.

So the interesting part isn't just:

"I have two views."

It's:

"What does each view trust?"

This became the main question for me

A simplified security stack might look like this:

security application
        |
        v
userspace interface
        |
        v
kernel interface
        |
        v
kernel structures
        |
        v
hardware

Every observer sits somewhere in that stack.

And every observer has a trust boundary.

If the attacker operates below it, the information above that boundary may no longer describe reality accurately.

That sounds theoretical, but RVBBIT gave me concrete examples of it.

A userspace process monitor can trust /proc.

Then kernel code changes what /proc reports.

A kernel detector can avoid that userspace problem.

But now the question becomes which kernel structures the detector trusts.

Move the observer down a layer and you don't eliminate trust. You move the trust boundary.

That is probably the biggest thing I learned from these projects.

Not how to unlink something from a list.

Not how to intercept a syscall.

Those are useful technical exercises, but the more general lesson was:

Detection is only as trustworthy as the assumptions behind the observer.

Where the two projects stand now

I think of the projects differently today.

Project RVBBIT is the original offensive research PoC.

It collects several established Linux kernel manipulation and concealment techniques in one place and provides a relatively compact environment for studying how they interact.

RVBBIT Arsenal is the continuation of that work.

Instead of asking only how visibility can be manipulated, it tries to reason about what remains visible afterward.

The relationship is roughly:

RVBBIT
   |
   |  How can I manipulate this view?
   v
RVBBIT Arsenal
   |
   |  What survives the manipulation?
   v
Detection research

Neither project is meant to represent production malware.

RVBBIT doesn't claim reliable evasion against modern EDR products.

It doesn't claim that the techniques are novel.

RvbbitSafe doesn't claim generic rootkit detection.

I think those limitations make the projects more useful, not less.

They make it possible to discuss what the code actually demonstrates instead of what an idealized rootkit or detector could theoretically do.

If I started RVBBIT again

I'd do one thing very differently.

I would document the defensive side while writing the offensive code.

For every mechanism, I'd keep notes around five questions:

What exactly am I changing?
Which observer stops seeing it?
Which state remains untouched?
Who could observe that remaining state?
How could that observation fail?

That would have saved me a lot of time later.

It also would have made the progression from RVBBIT to Arsenal much more obvious from the beginning.

But I probably wouldn't have understood why those questions mattered without first building the offensive side.

So maybe doing it backwards was useful after all.

What's next

I don't currently think RVBBIT needs a huge list of additional concealment features.

There are already enough mechanisms there to ask interesting questions.

I'm more interested in going deeper into:

Linux kernel observability;
cross-view detection;
kernel integrity;
eBPF-based telemetry;
sensor integrity;
trust boundaries;
the difference between an object's state and its representation.

In other words, I'm still interested in offensive kernel techniques.

I'm just increasingly interested in what they teach us about defense.

RVBBIT started with a fairly simple question:

How can kernel code change what userspace sees?

The question I'm left with is better:

If I can't trust what I'm seeing, where can I get another view?

I don't think there is one universal answer.

That's exactly why I want to keep working on it.

Projects

Project RVBBIT — Linux Kernel Rootkit Research PoC
https://github.com/buter-chkalova/project-rvbbit

RVBBIT Arsenal — Offensive & Defensive Linux Kernel Security Research
https://github.com/buter-chkalova/rvbbit-arsenal

Independent technical coverage

Hackplayers (Spain)
RVBBIT: anatomía de un rootkit LKM moderno basado en stealth, DKOM y anti-eBPF
https://www.hackplayers.com/2026/04/rvbbit-anatomia-de-un-rootkit-lkm.html

CSDN (China)
内核里的“幽灵”：一套Linux Rootkit隐身术完全拆解
https://blog.csdn.net/chen1415886044/article/details/161462914

RVBBIT and RVBBIT Arsenal are research projects intended for cybersecurity education, controlled laboratory experimentation, malware analysis, and defensive security research. Kernel-level experiments should only be performed on systems you own or where you have explicit authorization.