Inspiration

We were inspired by a simple problem: downloading a file requires a lot of trust. A file can look completely normal, yet the user often has no easy way to know what it will actually do once opened.

Traditional security tools often focus on identifying known threats. We wanted to explore a different question: what if, instead of immediately trusting or blocking a file, we could safely let it reveal its behavior?

That idea became Glassbox. Suspicious files are placed inside an isolated, disposable virtual machine designed to resemble a real computer. Glassbox can then observe their behavior in a controlled environment before the user decides whether the file should be trusted.

Our goal was to make malware analysis more understandable and useful to everyday users: see what a file does before you trust it.

What it does

Glassbox is a behavioral malware analysis sandbox that helps users determine whether an unknown file is safe before trusting it.

When a file is submitted, Glassbox launches an isolated, disposable virtual machine containing a realistic synthetic environment. The file can then be analyzed inside this sandbox while Glassbox observes its behavior, such as changes to the filesystem, system activity, and network interactions.

Rather than relying only on whether a file matches a known malware signature, Glassbox focuses on what the file actually attempts to do. Suspicious behaviors can then be combined into an understandable report that helps the user evaluate the potential threat.

Because execution happens inside an isolated virtual machine, the user's main system remains separated from the analyzed file. After analysis, the virtual environment can be discarded and reset for the next file.

In short, Glassbox lets potentially dangerous files reveal their behavior in a controlled environment before they are trusted on the user's real computer.

How we built it

Glassbox was built with AI around a Python application that manages the entire sandboxing process. We used Tkinter to create the desktop interface and QEMU to launch isolated Linux virtual machines where potentially suspicious files can be analyzed.

When Glassbox starts an analysis, it creates a disposable VM and communicates with it over SSH. We configured the VM automatically using cloud-init, including a dedicated sandbox user and key-based authentication. QEMU networking keeps the virtual machine separated from the host while still allowing Glassbox to communicate with it.

Inside the VM, we created a synthetic environment designed to resemble a real user's computer. This gives suspicious software realistic files and system resources to interact with while keeping the user's actual data separate. Glassbox can use this environment to observe what a file attempts to do rather than relying entirely on known malware signatures.

We also designed the system around disposable virtual environments. After an analysis, the VM can be shut down and reset so changes made by the analyzed file do not carry over into future tests.

The current prototype uses a Linux ARM64 virtual machine, with the architecture designed so additional host and guest configurations can be added in the future.

Challenges we ran into

One of our biggest challenges was getting the virtual machine infrastructure working reliably. Because Glassbox depends on launching an isolated environment automatically, we had to configure QEMU, virtual disks, networking, and communication between the host application and guest operating system.

ARM64 virtualization was particularly challenging. Our Linux VM initially appeared to start but would not boot correctly until we identified that it required the proper UEFI firmware configuration. We also encountered issues with virtual disk locks when VMs did not shut down cleanly, which led us to implement automatic VM cleanup.

Another major challenge was communicating with the VM. We needed Glassbox to know when the guest had fully booted before sending commands, so we implemented SSH readiness checks, key-based authentication, cloud-init configuration, and port forwarding between the host and VM.

Creating a realistic synthetic environment also introduced challenges. We needed suspicious files to believe they were interacting with a normal computer while ensuring that real user data remained separate.

These challenges taught us that building the malware-analysis logic is only part of the problem. Creating a reliable, isolated environment where potentially malicious software can safely run is itself a significant engineering challenge.

Accomplishments that we're proud of

We’re proud that Glassbox grew from an idea into a working prototype that can automatically launch and communicate with an isolated virtual machine.

One of our biggest accomplishments was building the virtualization pipeline itself. Glassbox can launch an ARM64 Linux VM through QEMU, configure it using cloud-init, establish secure key-based SSH communication, and automatically shut the environment down when it is no longer needed.

We also created a synthetic computer environment that can give suspicious files realistic data and resources to interact with without exposing the user’s real files. This lays the foundation for observing malicious behavior in a safer and more controlled environment.

We’re especially proud of how many low-level problems we overcame while building the prototype, including ARM64 boot configuration, UEFI firmware, virtual networking, SSH authentication, VM readiness detection, disk locking, and automatic cleanup.

Most importantly, we demonstrated that the core Glassbox concept is technically possible: creating an isolated environment where an unknown file can be examined before it is trusted on the user’s real system.

What we learned

Building Glassbox taught us that cybersecurity is not only about detecting malicious code—it is also about creating a secure environment where that code can be observed safely.

We learned a great deal about virtualization and how technologies such as QEMU, virtual disks, UEFI firmware, cloud-init, SSH, and virtual networking work together. Debugging the ARM64 virtual machine also showed us how much happens behind the scenes just to reliably start, configure, communicate with, and shut down an isolated system.

We also learned that behavioral malware detection presents different challenges from traditional signature-based detection. A single action may be completely harmless on its own, so meaningful detection requires looking at multiple behaviors and the context in which they occur.

Another important lesson was the value of synthetic environments. Instead of exposing real user information, a sandbox can provide realistic fake data that gives suspicious software something to interact with while keeping actual user data separate.

Most importantly, we learned how to take a large cybersecurity idea and break it into smaller engineering problems—virtualization, isolation, communication, monitoring, analysis, and cleanup—and gradually turn those pieces into a working prototype.