Hacker News Reader

Comment by cosmie | Hacker News Reader

Back in the good ol' days, you could just take the exam inside of a VM. The VM is locked down, but the host isn't.

Looks like from ProctorU's docs[1] that they got around to probing for the (blatantly obvious[2]) signatures of a VM and stopped that trick.

I wonder if those signatures exist in a Windows Sandbox[3] instance, or if you can detect/block the Enhanced RDP Session Windows leverages when running a Sandbox...

[1] Under "Not Supported" at https://support.proctoru.com/hc/en-us/articles/115011772748-...

[2] https://bannedit.github.io/Virtual-Machine-Detection-In-The-...

[3] https://docs.microsoft.com/en-us/windows/security/threat-pro...

View on HN

Many of the onerous requirements mentioned in the article are about the test taker and the environment they are in, not hte computer envirionment.

A VM doesn't help you when your professor is requiring you to rearrange your room, set up mirrors, bash earplugs etc.

I would record a video in advance or failing that flunk out. This calls for absolute rebellion against the system

The videos tend to be random, in both operations requested and their order.

If you can generate convincing real-time fake video based on verbal commands like “ok, now show me behind the desk… now your left ear” you probably don’t need to pass an exam any more.

My rebellious streak would implore me to make the process as awkward for the proctor as possible. Get creative.

Not that it would really help anything.

Tests, like software interviews, are a poor way to determine an individual's ability in anything but synthetic tasks. They are cheap, though.

That's exactly it - all of the onerous requirements are explicitly not about the computer, because the professors are presuming the software has that covered.

Except higher education software is known more for milking it's market than for it's robustness and sophistication. The type of proctoring software used here was trivially bypassed only a few years ago, when the last of my friends were finishing up college. I haven't been exposed to the topic since the last of them graduated, and from ProctorU's help center it looks like the vendors have wised up to the VM trick (in some fashion). But it can still likely be subverted relatively easily, rendering all of those onerous environmental requirements moot since they all explicitly ignore the computer itself.

I sort of wish I had access to it, so I could probe around myself and write up a tutorial. Not that I'm an advocate of cheating, but more so as a big "F* You" to the entire draconian process.

I'm the kind of person who dropped out of college anyway, so it really doesn't matter. But I would have told any professor pulling this nonsense to get stuffed.

This is far less about cheating than petty power tripping. (They should, of course, feel free to abuse each other in what ever ways they find enjoyable. But this is really not my thing.)

This would almost certainly not work and you'd just get a 0 on the exam

Can I ask, in a totally non-confrontational way, are you successful in your field and used to getting what you want? Based off of nothing other than this post I would guess that is the case

Just get a monitor that supports Picture in Picture use two computers instead of one.

Wow that’s creative.

Or a HDMI switcher and switch between your main PC and an (easily hideable) Raspberry Pi.

I would be in favor of a VM that is indistinguishable from a non-VM host. Is there any project that helps bring such functionality to, say, VirtualBox?

Not because I encourage cheating, but because I should never have to install proprietary software on my personal machine to take an exam. I will however on occasion grudingly be okay with installing closed-source software inside of a VM.

Do you have any proprietary code running on your machine, or would you just not install any to take an exam?

I run Linux and I don't believe I have any closed-source code on my machine at the moment that's not inside of a VM except for NVIDIA drivers.

I usually use VMs if I need to run anything closed source.

You don't need to be entirely vegan about closed-source to care about this issue though; there is a notion of a person trusting certain companies' closed source code over others. That is a thing. For example I would probably trust something like Photoshop slightly more than some random exam company's outsourced exam app.

Looks like there's one here: https://github.com/hfiref0x/VBoxHardenedLoader/blob/master/B...

Alternately, it seems that QEMU on linux does a pretty good job as well.

Malware often tries to do the same "am I running in a VM" checks to evade researchers' attempts to analyse it, and of course people want VMs in general to become indistinguishable from physical machines, so you're in good company.

I wonder how feasible it is to remove such fingerprints - find a way to make the VM be functionally indistinguishable from the host.

This is an old problem for reverse engineers, and there are some solutions, for example VBoxHardenedLoader [0]. As per usual with such things, these tools are in cat/mouse category.

[0] https://github.com/hfiref0x/VBoxHardenedLoader

That's interesting - I would have guessed that after a certain point, a VM and a physical computer are indistinguishable from the POV of software running inside.

It's easy to make the core device indistinguishable. It's the additional hardware that becomes a problem: QEMU/libvirt hardcodes its hard drive model to include the word "QEMU" (although there is an unmerged patch to make that configurable), and although I don't know how graphics work in a VM, it's far easier to create a higher-level graphics device than e.g. emulating Intel graphics.

I imagine a script could be used with qemu - given that patch you mentioned, which I would love a source for if you have it - to match the names of the virtual devices with names of devices on the physical host. Then there's no way for software to check the device names against a list of VM tools, since it always matches real, physical hardware.

At that point, it seems to me that there isn't much left to distinguish the virtual machine from the physical. Behavioral properties of the CPU? Anyway, that's what I meant when I said it seems like after a certain point, it becomes impossible to tell the difference.

EDIT: based on the link above, it looks like current state-of-the-art doesn't go far beyond making sure names and common virtualbox performance shortcuts aren't present. https://github.com/hfiref0x/VBoxHardenedLoader/blob/master/B...

This is a classic computer science question of whether the OS should be aware that it's being virtualized.

One of the other telltale signs of a VM are "things VMs can do that physical devices can't" - such as weird screen resolutions (when running in windowed mode rather than full screen), weird CPU core counts, physical ram values that aren't cleanly divisible into DIMM slots, etc.

Good point. I guess that would be relatively easy to check for programmatically.

What else is there that could possibly indicate virtualization? Available instruction sets? Strange limitations of the given CPU? (e.g., the cpu presents itself as some Intel chip that's known to have 4 cores, but there's only 2 available)

patch is https://lists.gnu.org/archive/html/qemu-devel/2012-03/msg021...

Thanks!

I know of malware long ago that would attempt to time how long CPU instructions take, based on the theory that a VM would be significantly slower, but more recently, especially with hardware-assisted virtualisation, the differences have become close to indistinguishable.

The video game anti-cheat world has been playing this cat and mouse game for a while. A few months back I saw an interesting article [0] describing some of the detection methods being used. It's fascinating to think about how much effort gets put into this.

[0] https://secret.club/2020/04/13/how-anti-cheats-detect-system...

There are certain tools often used for malware testing such as Cuckoo that can help conceal some of the more obvious tells.

- You run into copyright issues, because unless you duplicate a commercial UEFI (SMBIOS and all that good stuff) within the VM you'll be detected.

- You run into performance issues - virtualization's speed depends on paravirtualized drivers, which are readily identifiable (e.g. "virtio" disk controller). These can be emulated instead of paravirtualized but will cost performance. Windows drivers are signed so you can't just change names of things.

- Chipsets - some are often emulated by VMs. For example, if you are running a system in 2020 and are using an Intel 440BX chipset, it's probably a VM.

For what it's worth, I play MMOs with malware anti cheats on a VM all the time with a Pci-pass-through setup. Event he ones that are known for detecting VMs don't seem to detect me under QEMU. Go figure.

You can also just duct tape a phone to your computer screen with your notes. Webcam can't see it, and it's right in your field of view when looking at the questions. Locked down browsers are dumb, no matter what you do there's a million ways to cheat easily.

I agree with you but this is trivially defeated with a mirror

If your VM is running on my computer, it is not locked down. I'm going to get in, and so will anyone else who really wants to.

Most of these applications simply look at your manufacturer if I'm remembering correctly (at the very most, it's one easily changeable property). You can generally get past these checks by setting any strings that reference VirtualBox or the likes to Dell.

The easiest one to check (from the browser) is the WebGL Renderer. I'm currently on a Mac running Windows 10 in a Parallels VM, and checking here[1] shows

  ANGLE (Parallels Display Adapter (WDDM) Direct3D11 vs_5_0 ps_5_0)

The "Parallels Display Adapter (WDDM)" seems to be coming from my Display Adapter name, which I could change. But I'm not sure if any other part of that string leaks my computer's status as a VM.

My non-standard screen resolution is another dead giveaway. There may be others as well, but those two seem to be the lowest hanging fruit. And many of these proctoring suites run as browser extensions, and I'm not sure what additional information extensions have access to.

But yea, they're not too hard to trick. You could get fancy, around listening for mouse clicks and keyboard taps, without detecting any corresponding actions within the VM. But that sounds like far too much effort for a higher education software vendor.

[1] https://browserleaks.com/webgl

Why not just run a livecd os.

Windows Sandbox doesn't fool exam monitoring software.

Reply on news.ycombinator.com