I thought maybe DOSBox securemode (command-line flag or enabled using CONFIG.COM from within DOSBox) would trick that detector, but it did not. I did not check the source code to see why. It seemed at least like a possibility that enabling it would make the special opcodes behave more like on the emulated CPU, since the point of securemode is to disable commands like MOUNT.
It never really occurred to me that you'd want to be able to detect if something is running in DOSBox, since I figured that the point was to be as compatible as possible with MS-DOS.
I guess it makes sense to try it anyway. Now I'm wondering how I'd be able to detect something like Concurrent DOS or REAL/32 or REAL/NG.
For me the opposite. I would have never though that there would be a point to trying to "detect" DOSBox since it would be trivial to do so. After all, DOSBox is not really designed to run MS-DOS, but its own DOS-like thing, and there must be a million small details that you can use to distinguish it from MS-DOS, if you really wanted to. I mean, the default filesystem is not even FAT...
_Even_ if you run the MS-DOS kernel in DOSBox, the builtin DOS literally leaks through in many places (e.g. many API services still available instead of crashing), with only some of the more recent forks even trying to hide it.
Testing if you're running under virtualization or emulation is a whole thing. We wrote virt-what to do this for virt and containers. It could do emulators as well if someone was motivated enough. It's basically a giant shell script. https://people.redhat.com/~rjones/virt-what/
There's also an adversarial aspect to this. Some emulators try to avoid detection and a lot of software tries to detect if it's running under virt for various reasons, eg. to stop cheating in games or stop reverse-engineering. (virt-what is deliberately not adversarial, it's very easy to "trick" it if you wanted to do that)
Makes sense; when I was doing WGU they explicitly forbid virtual machines, which makes enough sense since if you're in a VM they can't see your full screen. It wouldn't surprise me if nowadays they have some sort of software detector to see if you're in a VM.
There are detectors for VMs, and modifications to allow VMs to evade those detectors. It's an arms race.
Example: There is (was? I don't actively follow the community) a patch set for a particular piece of VM software that made it undetectable to anti-cheat in games.
While I don't use said software (I have a casual interest in it only...would be nice to get more games working on Linux), I have to disclose that I'm against anti-cheat mechanisms. I'm a software engineer, and I've worked on a few smaller games, and know the overall structure of bigger ones, and I don't think I've ever seen a game use good practices in multiplayer. Instead, they usually rely on client side code and lean on anti-cheat software to stop cheaters.
Sorry, Western Governors University. It's an online school.
When taking a test they have a proctor that's watching you on a webcam, and they make you pan the webcam around the room to ensure that there's no obvious way to cheat, and they make you share your screen to ensure you only have a browser running.
When I took final exams or industry certifications, I reported in-person to the Testing Center at community college. The center is custom built for secure proctoring exams. You check in with ID, you stash your watch, phone and wallet in a locker, and you use a secure computer in a monitored quiet room.
It’s perfect for all parties, and doesn’t intrude on your personal living space or devices.
> and they make you pan the webcam around the room to ensure that there's no obvious way to cheat, and they make you share your screen to ensure you only have a browser running.
Well that level of intrusiveness would just make me come up with something overly complicated just so I could prove that I could cheat if I wanted.
I thought maybe DOSBox securemode (command-line flag or enabled using CONFIG.COM from within DOSBox) would trick that detector, but it did not. I did not check the source code to see why. It seemed at least like a possibility that enabling it would make the special opcodes behave more like on the emulated CPU, since the point of securemode is to disable commands like MOUNT.
It never really occurred to me that you'd want to be able to detect if something is running in DOSBox, since I figured that the point was to be as compatible as possible with MS-DOS.
I guess it makes sense to try it anyway. Now I'm wondering how I'd be able to detect something like Concurrent DOS or REAL/32 or REAL/NG.
For me the opposite. I would have never though that there would be a point to trying to "detect" DOSBox since it would be trivial to do so. After all, DOSBox is not really designed to run MS-DOS, but its own DOS-like thing, and there must be a million small details that you can use to distinguish it from MS-DOS, if you really wanted to. I mean, the default filesystem is not even FAT...
_Even_ if you run the MS-DOS kernel in DOSBox, the builtin DOS literally leaks through in many places (e.g. many API services still available instead of crashing), with only some of the more recent forks even trying to hide it.
DOSBox-X might fake it well enough.
Testing if you're running under virtualization or emulation is a whole thing. We wrote virt-what to do this for virt and containers. It could do emulators as well if someone was motivated enough. It's basically a giant shell script. https://people.redhat.com/~rjones/virt-what/
There's also an adversarial aspect to this. Some emulators try to avoid detection and a lot of software tries to detect if it's running under virt for various reasons, eg. to stop cheating in games or stop reverse-engineering. (virt-what is deliberately not adversarial, it's very easy to "trick" it if you wanted to do that)
Makes sense; when I was doing WGU they explicitly forbid virtual machines, which makes enough sense since if you're in a VM they can't see your full screen. It wouldn't surprise me if nowadays they have some sort of software detector to see if you're in a VM.
There are detectors for VMs, and modifications to allow VMs to evade those detectors. It's an arms race.
Example: There is (was? I don't actively follow the community) a patch set for a particular piece of VM software that made it undetectable to anti-cheat in games.
While I don't use said software (I have a casual interest in it only...would be nice to get more games working on Linux), I have to disclose that I'm against anti-cheat mechanisms. I'm a software engineer, and I've worked on a few smaller games, and know the overall structure of bigger ones, and I don't think I've ever seen a game use good practices in multiplayer. Instead, they usually rely on client side code and lean on anti-cheat software to stop cheaters.
> when I was doing WGU they explicitly forbid virtual machines,
What's WGU in this context?
> which makes enough sense since if you're in a VM they can't see your full screen
Presumably they can't also see the screen of another device...
Sorry, Western Governors University. It's an online school.
When taking a test they have a proctor that's watching you on a webcam, and they make you pan the webcam around the room to ensure that there's no obvious way to cheat, and they make you share your screen to ensure you only have a browser running.
When I took final exams or industry certifications, I reported in-person to the Testing Center at community college. The center is custom built for secure proctoring exams. You check in with ID, you stash your watch, phone and wallet in a locker, and you use a secure computer in a monitored quiet room.
It’s perfect for all parties, and doesn’t intrude on your personal living space or devices.
> and they make you pan the webcam around the room to ensure that there's no obvious way to cheat, and they make you share your screen to ensure you only have a browser running.
Well that level of intrusiveness would just make me come up with something overly complicated just so I could prove that I could cheat if I wanted.